WordPress 会通过加入块协议而受益吗？ 还是努力不值得麻烦？ 在本文中，我将对这些问题提供我个人的答案。
块协议是最近推出的规范，允许 JavaScript 块可跨应用程序重用。 由于 WordPress 创始人 Matt Mullenweg 表现出他对该项目的兴趣，我决定通过几篇文章来探讨将 WordPress 编辑器集成到 Block Protocol 的优点和缺点：
现在剩下的就是理解所有这些信息，并回答关键（和终极）问题：加入 Block Protocol 是否会使 WordPress 受益？ 还是努力不值得麻烦？
在本文中，我将对这些问题提供我个人的答案。
快速复审
让我们首先快速总结一下 WordPress 加入块协议的潜在好处，正如我在第一篇文章中介绍的那样，以及相关成本，正如我在第二篇文章中描述的那样。
WordPress 加入块协议的潜在好处
来自开放网络的开发人员可能会受益于：
- 有权访问他们自己的应用程序的 WordPress 块（无论是否基于 WordPress）。
- 加入 WordPress 社区生产和维护区块的努力，目前每个新版本的 WordPress 都涉及数百名志愿者，然后在他们的应用程序中重用这些公共资源。
- 相信 Block Protocol 会在长期内得到强有力的支持，因为像 WordPress 这样的大采用者会给这个项目带来可信度和吸引力。
WordPress 社区可能会受益于：
- 通过将其范围扩展到现代 Web 开发堆栈的一个新组件，让 WordPress 跟上其发展步伐：为客户端提供支持的基于 JavaScript 的块。
- 针对更多的贡献者，并具有多样化的技能，尤其是在 JavaScript 和 CSS 方面。
- 有权访问为非 WordPress 应用程序创建的开源块，以支持他们的 WordPress 网站。
- 将 WordPress 编辑器与 Gutenberg 分离，以便 Gutenberg 块还可以提供动态功能来为面向公众的 WordPress 站点（除了 Gutenberg 目前所在的 wp-admin 之外）提供动力，这可能在即将到来的第 3 阶段特别有用古腾堡（专注于合作）。
- 能够为动态功能创建 DRY 代码，仅由 JavaScript 组成，而不是像目前发生的那样同时包含 JavaScript 和 PHP（JavaScript 用于 wp-admin 中的编辑器，PHP 用于面向公众的站点）。
- 使用 WordPress 领域之外的开发，例如生成静态站点的潜在项目来记录应用程序中的所有块。
- 改进了对 GraphQL 的支持，允许对数组和对象进行强类型化。
遵守区块协议的成本和缺点
- 目前尚不清楚如何处理块样式，并且当前的解决方案还不够全面，无法保证我们的块可以以某种所需的方式设置样式。
- 通用块很容易变得臃肿（或有被淹没的风险），减慢网站的加载速度并不必要地消耗更多的能量。
- 通用块（很可能）不如原生块好
- 调整 JSON 模式会产生重大变化或增加复杂性
- 这将限制 Gutenberg 自定义功能的开发，因为 Block Protocol 不支持这些功能
- 目前还没有 Block Protocol 应用程序的示例，因此与 Gutenberg 的集成没有可效仿的示例。
- 目前还没有 Block Protocol 应用程序的生态系统，因此集成的潜在好处，即在 WordPress 之外使用 Gutenberg 块，可能永远不会实现。
- Block Protocol 仍然是一个草案，我们可以期待在 v1.0 发布之前进行有意义的修改。
资源会从哪里来？
无论是 Gutenberg 原生支持 Block Protocol，还是仅在运行连接两种相应格式的脚本后才进行集成，我们都可以预期开发工作所需的不可忽视的投资。 这个成本不是一次性的：在实施解决方案之后，它仍然必须从那时起维护，以确保它与古腾堡的每个新迭代兼容。
谁将贡献这项必要的工作？
如果这项任务落在了 WordPress 社区的肩上，这可能会成为一笔巨大的开支，因为这些贡献者无法解决其他问题。 有多少工作要做？ 实际上，相当多。
如果我们注意 Gutenberg issues中的未解决问题的数量，目前已超过 4000 个，而且这个数字还在增加。 例如，在我写这篇文章之前的 24 小时内，创建了 11 个新问题：
如果我们检查 1 个月期间的见解，我们会发现新问题的数量超过了正在解决的问题数量：
这种情况不仅发生在古腾堡，也发生在 WordPress 核心。 Daniele Scasciafratte 对 WordPress Core Trac 中的票证进行了分析，他表明，一旦第一个补丁可用，票证仍然需要平均 2 到 3 年才能得到解决。 丹尼尔以一个严峻的评估结束：
我对核心开发的看法是，自从 Gutenberg 到来以来，它就处于停滞状态，核心开发掌握在极少数人手中（就像 5.0 版本那样随时可能离开），而且在 “高级”贡献者的实际数量跟上每天制作的门票和补丁数量。
此外，让我们注意到古腾堡已经超过 5 年了：由于项目的（可能出乎意料的）复杂性，花了这么长时间才能够发布完整站点编辑（使用 WordPress 5.9），即便如此，它仍然是 正在进行中的工作。
这种进展速度比最初预测的要慢，这就是古腾堡的第三和第四阶段被推迟的原因。 当 Matt Mullenweg 在 WordCamp US 2018 期间首次公布古腾堡 4 个阶段的时间表时，第 3 阶段的目标是 2020 年，但现在预计第 3 阶段将在 2022 年 5 月发布 WordPress 6.0 之后开始。
考虑到 WordPress 开发人员的盘子已经有多少，我们是否需要继续添加新的开发？
区块协议是否无法实现其目标？
并非社区中的每个人都相信 Block Protocol 可以真正兑现其承诺。 WP-CLI 维护者 Alain Schlesser 在他的 Twitter 帖子中表示，通用块的概念是有缺陷的，因为它永远无法满足每个人的需求：
恕我直言不讳，但对我来说，这听起来像是解决网络最大问题之一的方法就是“解决问题”……
我不认为我们缺乏将结构化数据传递给组件的方法。 我们缺乏适用于每个人的用例的标准化解释。
——阿兰·施莱瑟（@schlessera），2022 年 1 月 28 日
如果 Alain 是对的，那意味着 Block Protocol 的既定目标无法实现，WordPress 应该远离它。
采用区块协议是一种赌注，失败的可能性很大
目前围绕区块协议有几个危险信号：
- 块协议的目标实际上可能无法实现（如上所述）
- 尚无应用程序展示其用途
- 规范仍是草案，重要部分（尤其是样式）仍不完整
- 我们不知道 v1.0 何时发布；如果规范要根据现实生活中的用例进行调整，那么还没有应用程序使用它的事实应该会降低对其在短期/中期发布的期望（如果我们从古腾堡那里吸取教训，我们应该知道复杂的项目可能需要比原计划更长的时间）
显然，采用区块协议将是一个冒险的赌注，失败的可能性很大。如果 WordPress 社区想要保持谨慎，而不是将精力投入到可能会失败的冒险中，那么它应该（至少目前）不致力于区块协议。
但并非一切都丢失了！即使 WordPress 不采用 Block Protocol，但这并不意味着 WordPress 无法从中受益！
将块协议视为“想法”，而不是“实施”
如果不采用块协议，WordPress 社区仍然可以尝试获得相同的潜在利益，或者至少是最重要的利益，并围绕它们制定行动计划。如果我们必须选择一项我们不能没有的好处，那会是哪一项？
我相信列表中的一个重要项目，它代表了 Matt Mullenweg 对块协议感兴趣的主要原因，它将使非 WordPress 应用程序能够更容易地嵌入 Gutenberg 块。 （事实上，Mullenweg 认为古腾堡“比 WordPress 更大”，尤其是在开放网络的背景下。）
WordPress 不需要块协议来实现这个大目标。那是因为块协议不仅仅是一个规范，也是一个“想法”。一旦我们了解了一个新的想法或概念，我们不仅可以设计一个，而且可以设计多条路径来使其成为现实。在这些路径中，会有一条可以达到相同的目标，但需要较少的努力。然后，块协议可以为这个想法提供模板，我们可以满足它，将自己限制在最适合 WordPress 的前提条件，并且始终在 WordPress 域内。
例如，在这些替代路径中，其中一个可以使用已经为 Gutenberg 定义的 JSON 模式，因此不需要产生向后不兼容的更改，也不需要在 WordPress 中维护两种不同的 JSON 模式格式。
适用于 WordPress 的可行想法
将块协议简单地作为想法的模板，并将它们调整为 WordPress，我们可以提出一个涉及以下项目的行动计划（以及可能的其他几个项目）：
古腾堡区块不应该期望古腾堡成为底层引擎
Gutenberg 块应通过明确定义的接口与底层引擎进行通信。可以使此接口上的方法与 Gutenberg API 定义的方法完全匹配。但是通过这样做，Gutenberg 将只是提供自己的接口，任何其他实现相同接口的引擎也可以嵌入 Gutenberg 块。
Gutenberg 块不应依赖于 WP REST API
与上面的项目类似，古腾堡块需要从某个地方获取数据，但他们不应该关心从哪里获取数据。与其依赖预定义的 REST API 端点，数据源应该是可注入的，允许任何应用程序提供自己的数据源。
在“组件”层最大化逻辑，在“块”层最小化它
块只是 JavaScript 组件的集合：
组件已经相当可重用。 如果我们的应用程序使用 React，并且我们需要实现一些日历功能，那么我们可以前往 npmjs.com，搜索“React calendar”，找到合适的组件并将其导入我们的应用程序。
它主要（如果不仅是）在组件和外部包装块之间的“粘合层”，代码在应用程序之间是不可重用的：
因此，我们可以实施一个非常明智的策略：我们可以放弃使我们的块可重用，而是简单地在组件级别提供可重用性，这已经是可行的。 然后，我们的主要任务就是尽可能的将代码从块层移动到组件层，在块层只保留依赖于 Gutenberg 并且无法抽象掉的代码，并确保组件上的所有代码 layer 是可重用的（即它的数据和属性是通过 props 注入的，而无需假设这些数据和属性来自何处）。
如果我们设法让 95% 的所有代码位于组件层，那么我们可以通过仅重新实现 5% 的块代码来为不同的应用程序重新创建块。 虽然这不如即插即用（正如 Block Protocol 所承诺的那样），但它仍然可以被认为是一个不错的权衡。
例如，对于我的 GraphQL API 插件，我创建了一个 GraphiQL 块，其整体逻辑几乎就是这段代码：
const EditBlock = ( props ) => {
const {
attributes: { query, variables },
setAttributes,
className,
} = props;
const onEditQuery = ( newValue ) =>
setAttributes( { query: newValue } );
const onEditVariables = ( newValue ) =>
setAttributes( { variables: newValue } );
return (
<div className={ className }>
<GraphiQL
fetcher={ graphQLFetcher }
query={ query }
variables={ variables }
onEditQuery={ onEditQuery }
onEditVariables={ onEditVariables }
docExplorerOpen={ false }
headerEditorEnabled={ false }
/>
</div>
);
}
<GraphiQL>组件由 graphiql 包提供。 块中超过 99% 的代码仅来自这个可重用的组件。 生成块只需要几行代码（不到总代码的 1%），属于 3 个用于块“粘合”代码的 JS 文件和 3 个用于样式的 SCSS 文件，因此将其移植到不同的 应用程序将需要很少的努力。
不要为块强加黑匣子
区块协议的样式难题（在很大程度上）是由于决定将区块视为黑匣子而发生的。 如果应用程序不知道块是如何构建的，并且它可以作为 props 传递的 CSS 属性（或变量）集是有限的，那么样式块将受到严重损害。
一个更好和更简单的解决方案是允许应用程序在块内部进行对等，并请求将 CSS 类名（具有预定义的命名格式）添加到每个 HTML 标记中。 这样，应用程序将知道块内部的行为方式，并且可以更全面地生成自定义 CSS 代码以根据需要对其进行样式设置。
结论
回到这篇文章的标题，“加入区块协议会让 WordPress 变得更好吗？”，现在我可以给出我的答案：
不，这不会更好。采用块协议是不值得的。
块协议是一个绝妙的主意。事实上，在我的第一篇文章中，我对它的兴奋是显而易见的。我写那篇文章是为了让 WordPress 社区关注块协议，因为我希望它被采用。
但在之后的几个月里，当我开始更详细地探索规范时，我开始相信相关的成本太高了，这使得冒险成为一个不值得追求的冒险。我现在已经完成了一个完整的周期。
尽管如此，跨应用程序可重用块的想法仍然令人信服。正如我在本文中所建议的，我们可以从块协议中获取一些想法并尝试实施。这些可能并不完美，但可以提供合理的收益和成本权衡。然后，我们仍然可以从采用块协议中获得一些好处，但只在 Gutenberg 内部工作，并充分利用任何对 WordPress 有意义的功能。
