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 有意义的功能。