它的三个主要组成部分是：
Preact与React和其他JavaScript框架（如Vue、Svelte或Solid）相比，在前端环境中具有许多优势（这是Interactivity API的重点）：
- 它很小：8kB，包括挂钩和信号.
- 它为我们提供了开箱即用的DOM差异。
- 通过他们的Option Hooks，它具有极强的可扩展性。他们使用钩子（preact/hooks）的可扩展性、与React（preact/compat）及其信号（@preact/signals）的兼容性。基本上，除了DOM困难算法之外的所有内容。
- 它的核心团队非常棒，非常有帮助。他们还对增强Preact的这种“基于岛屿”的用法感兴趣。
不。目前，还没有进行这种过渡的计划。作为一个完全交互式的应用程序，编辑器的要求和优点是完全不同的。Preact确实有@前置/兼容该软件包能够与React生态系统完全兼容，许多大型web应用程序都使用它。然而，在块编辑器中使用Preact不会像在Interactivity API的前端那样提供优势。
会议考虑了许多替代方法。以下是其中一些内容的简要总结：
首先考虑React是因为Gutenberg开发人员熟悉它。也考虑了其他流行的JS框架，如Svelte、Vue.JS或Angular，但它们（包括React）都不支持PHP，也不兼容WordPress挂钩或国际化。
js是一个很棒的框架，它激发了Interactivity API中的许多功能。然而，它不支持服务器端呈现其指令有一个为WordPress块量身定制的类似系统有很多好处。
选择Preact而不是Alpine.js的原因有很多，比如它的尺寸更小，性能更好（特别是添加了信号)事实上，自定义指令是用Preact的声明性语法和工具（钩子、信号）编写的，它经过了更多的测试，比Alpine.js拥有更大的社区。它还与React兼容（用于从编辑器共享客户端呈现的组件），并且它为Interactivity API提供了最快的开箱即用DOM差异算法，包括UI状态保持。
此外，由于Preact在后台运行，Interactivity API管理“最后一层”，因此可以更好地适应WordPress的要求。例如，指令中不允许使用JavaScript表达式，以避免安全风险并确保符合严格的安全策略，并且所有WordPress指令都是符合规范的HTML属性。
请参阅下面的答案。
创建数字用户线对于编写交互式模板也进行了研究。然后，用该模板DSL编写的代码将被编译成JavaScript和PHP。然而，创建一个production-gradeTemplate编译器是复杂的，并且是一项巨大的风险投资。这种方法在未来仍在考虑中，指令将作为编译目标。
在前端使用React在PHP的服务器渲染中无法顺利工作。使用React呈现块的每种方法都必须使用客户端JavaScript加载内容。如果只在客户端上渲染块，通常会导致用户体验不佳，因为用户在等待加载内容时盯着空的占位符和微调器。
在PHP扩展（如v8js）中使用JS也是可能的，但不幸的是，PHP扩展不是向后兼容的，只能在存在PHP回退时使用。
现在，可以用PHP服务器渲染块了和使用React在前端渲染同一块。然而，这会导致开发人员体验不佳，因为必须跨PHP和React部分复制逻辑。不仅如此，你现在还暴露在WordPress挂钩引起的微妙错误中！
想象一下，安装一个带有钩子（过滤器）的第三方插件，该钩子可以修改服务器重新渲染的HTML。假设这个过滤器将一个CSS类添加到块的HTML中。该CSS类将出现在服务器渲染的标记中。在前端，您的块将再次在React中呈现，但现在内容将不包括CSS类，因为无法将WordPress挂钩应用于React-rendered内容！
另一方面，Interactivity API被设计为与WordPress挂钩完美配合，因为指令通过行为增强了服务器渲染的HTML。这也意味着它可以与像i18n这样的WordPress后端API开箱即用。
总之，使用Interactivity API而不仅仅是使用React具有以下优点：
- 如果使用React，则交互块必须在客户端上生成与在PHP服务器上相同的标记。使用交互API，不需要将指令添加到服务器呈现的HTML中。
- 交互API对PHP更友好。它可以与WordPress挂钩或其他服务器功能（如国际化）一起使用。例如，使用React时，您无法知道服务器上应用了哪些挂钩，并且在水合作用后，这些挂钩的修改将被覆盖。
- 所有的好处使用标准.
主要区别是交互API是陈述式和反应式因此，编写和维护复杂的交互体验应该变得更加容易。此外，它已经专门设计用于处理块提供了一个具有上述优点的标准，如块间通信、兼容性或客户端导航等站点范围的功能。
最后，将其与jQuery进行比较，Interactivity API运行时约为10kb，重量轻得多。事实上，目前正在努力在WordPress生态系统中删除像jQuery这样的重框架，这将在这方面有所帮助。
如果您想使用此API将前端交互添加到块中，那么简单的答案是肯定的。如果块不是交互式的，则块创建工作流将保持不变。
交互API引入了一种新的标准方法，以便于将交互行为集成到WordPress的前端部分。这意味着您仍然需要使用React来处理块的编辑器部分。
另一方面，如果你想用Interactivity API创建一个交互式块，你不需要处理复杂的主题，比如工具、与WordPress的集成、块间通信或交互部分的服务器端渲染。
当然，是的，它不仅限于区块。您会看到很多关于Interactivity API如何提供创建交互式块的标准的介绍，但这只是因为这是最常见的用例。更一般地说，交互API标准可以用于在WordPress的任何部分的前端添加“交互行为”。
请参阅wp_交互_处理_纠正功能有关在带有任意HTML的块外部使用Interactivity API的详细信息。
不可以。Interactivity API之外的块可以与使用它的块共存。但是，如上所述，请记住使用API的块有一些好处：
- 模块之间可以轻松通信。使用标准，默认情况下处理此通信。当不同的块使用不同的方法进行前端交互时，块间通信变得更加复杂，并且在单独的开发人员创建块时几乎不可能实现。
- 可组合性和兼容性：您可以组合交互式块，将它们嵌套在具有定义行为的结构中，并且由于遵循相同的标准，它们完全是交叉兼容的。如果每个块使用不同的交互方法，它们可能会中断。
- 发送到浏览器的KB更少。如果每个插件作者使用不同的JS框架，则会在前端加载更多代码。如果所有的块都使用相同的块，那么代码将被重用。
- 如果页面上的所有块都使用此标准，则可以启用客户端导航等站点范围的功能。
API的设计考虑到了性能，因此它不应该是一个问题：
- 指令所需的运行时代码仅为~10 KB，所有块只需加载一次。
- 属于Interactivity API的所有脚本模块（包括
视图.js文件）将在不阻止页面呈现的情况下加载。
- 有正在进行的探索关于块进入视口后延迟脚本加载这样，可以在不影响用户体验的情况下优化初始负载。
由于Interactivity API与服务器端呈现完美结合，您可以使用所有WordPress API，包括__()和_e（）。您可以使用它来翻译HTML中的文本（就像您通常会做的那样），甚至可以在以下情况下在商店内使用它：使用wp_interactivity_state（）在服务器端。它可能看起来像这样：
//渲染.phpwp_interactivity_state（“收藏夹电影”，数组(“1”=>数组(“id”=>“123-abc”，“movieName”=>__（“someMovieName“，”textdomain“）),) );
目前正在开发与脚本模块兼容的翻译API（交互API需要）。检查#60234跟踪这项工作的进展。
否。交互API只允许工具书类作为值传递给指令。这样，就不需要eval（）完整的JavaScript表达式，因此不可能执行XSS攻击。
对。交互API不使用评估（）或者函数（）构造函数，因此它不会违反不安全有效内容安全策略。它还可以与任何自定义内容安全策略.
当然。指令调用的操作和回调可以执行JavaScript函数可以执行的任何操作，包括发出API请求。