React-Gutenberg Bridge 简介：Headless Block 支持更好的编辑体验

您对无头 WordPress 提供的机会感到兴奋，但您客户的营销团队依赖于所见即所得的古腾堡编辑器。

了解 Faust 对无头项目的新 Gutenberg 块支持如何将两者结合在一起，使您的开发现代化，同时为您的营销人员提供支持。

演讲嘉宾：

• WP Engine 的软件工程师 Teresa Gobble
• WP Engine 高级软件工程师 Blake Wilson

会议幻灯片：

成绩单：

TERESA GOBBLE： 大家好。 我的名字是特蕾莎·戈布尔。 我是 Faust 团队的 WP Engine 软件工程师。

我和高级软件工程师 Blake Wilson 在这里向您介绍 React-Gutenberg Bridge——无头块支持，可提供更好的编辑体验。 欢迎。 让我们开始吧。

所以今天，我们有很多内容要讲。 首先，我将介绍一些与问题相关的事情和我们为您提供的解决方案，以及 React-Gutenberg Bridge 的价值。 然后我们将去找 Blake，他将为我们提供 React-Gutenberg Bridge 的实际演示。 之后，我们将讨论几个技术细节。 我们还将访问我们为此准备的未来路线图。

所以这就是问题所在。 没有将 Gutenberg 块从 WordPress 转换为无头前端的简化方法。 现有的解决方案尚不能扩展或直观地提供无头开发人员可以期望的开发人员体验。

解耦打破了在编辑器中自然使用古腾堡块内容的能力。 各机构想知道他们是如何按照自己的方式或在几乎没有指导的情况下从头开始的。 还有很多悬而未决的问题留给人们。

造型呢？ 可重用性、动态块、InnerBlocks 怎么样？ 那么，这就是 React-Gutenberg Bridge 的用武之地。它是一个分为两部分的解决方案 - 首先，一种以编程方式公开 Gutenberg 块的方法，以便可以在无头前端解析和读取它们。 这篇文章叫做 WPGraphQL Content Blocks。

其次，我们有一个连接器来方便在无头前端中设置和渲染这些块。 这是一个名为 Faust WP Blocks 的包。 在这里，您将看到它如何与这两个解决方案一起工作的演练。

您网站的基于 React 的后端有其 Gutenberg 块，这些块由 WPGraphQL Content Blocks 插件公开。 它将 block.json 内容公开给 WPGraphQL。 它将它提供给名为 WPGraphQL 的插件。

然后它转到连接器包，它支持块的定制、发现和渲染。 在我们今天进行技术讨论和演示时，实际上将对此进行更多讨论。 那么这会给你的团队带来什么样的价值呢？

好吧，这是一个端到端的固执己见的解决方案，可以降低复杂性和歧义。 它通过遵循特定的约定来节省开发时间。 它允许组合使用块和块模式。 它可以一遍又一遍地重复使用。 现在您已经了解了 React-Gutenberg Bridge 的工作原理，让我们去 Blake 看看它的实际演示。

布莱克·威尔逊： 谢谢，特蕾莎。 大家好。 我是布莱克·威尔逊。 我是 WP Engine 的一名高级软件工程师。

我在构建 Faust 的 Faust JS 团队中。 我今天为您提供了一个非常棒的演示，展示了我们为帮助协调这个 React-Gutenberg Bridge 而构建的两个组件。 因此，让我们开始吧。

首先，我将向您展示我在此处设置的内容。 然后我们可以进入实际代码，看看我们在那里得到了什么。 所以对于初学者来说，我有一个在本地运行的 WordPress 网站。

我安装了一些插件。 所以我得到了浮士德插件。 这有助于促进 Faust JS 站点上的预览和所有这些好东西。 我有 WPGraphQL，这是将您的 WordPress 站点转换为 GraphQL 端点所必需的。

然后我得到了 WPGraphQL 内容块。 所以这是我们为帮助促进这个 React-Gutenberg Bridge 而构建的插件之一。 该解决方案分为两个主要部分。

因此，我们已经获得了其中一部分，可以通过 WPGraphQL 以编程方式实际公开 Gutenberg Block 数据，然后另一部分可以在您的 Faust JS 前端上使用它。 让我们先看看 WPGraphQL 内容块及其工作原理。

所以我们将进入我们的图形 IDE。 我在此处设置了此查询以获取页面数据。 所以在这种情况下，我们只是获取页面的标题。

所以 GraphQL 内容块所做的是在您的 GraphQL 模式中公开内容块类型。 因此，如果我们输入内容块，您可以在此处看到，我们将获取此给定页面和此页面上所有块的信息。 让我们过去并编辑此页面并添加一些内容。

所以我们将弹出示例页面。 你可以在这里看到我们有一张白纸。 因此，让我们继续创建一些块。 让我们在这里创建一些列。

我们将做一个 50/50 的专栏。 让我们在这一半上添加一个段落，然后在这一半上添加图像。 所以我的媒体库中有一张图片。 让我们继续把这个放进去。

你可以在这里看到，我们有两列。 同样，左侧是一段，右侧是图像。 所以让我们更新一下。 让我们回到 WPGraphQL 内容块，看看我们得到了什么结果。

所以你可以在这里看到，现在我们有两个内容块。 这里的第一个是核心专栏，核心专栏。 然后我们在里面得到渲染的 HTML。

所以 WPGraphQL 内容块的伟大之处在于我们也处理 InnerBlocks。 所以你可以在这里看到，如果我们向名为 flat true 的内容块添加一个参数，你现在可以看到我们实际上得到了那些列中的所有块。 所以我们也在为你处理那个案子。

我们得到一个核心栏目，核心栏目，核心段落，核心图像。 所以所有这些都是以编程方式为您完成的。 现在，您可以在前端使用此块数据。 因此，让我们在这里更深入地挖掘一下。

假设我们想要它的一些属性。 我们可以使用 GraphQL 中的联合来使用它。 所以我们将在核心图像上做，获取属性。 例如，假设我们想要标题。

所以你可以看到这里没有标题。 让我们回到示例页面。 我们将继续并在此处添加标题。 我的字幕。 更新那个。

如果我们刷新此查询，我们现在可以看到，我们正在将我的标题作为 WPGraphQL 内容块中的适当属性。 所以这是解决方案的第 1 部分。 现在，我们实际上可以获得我们所有的古腾堡块数据，并使用它在我们的前端使用它。

因此，让我们跳转到 VS Code，我们将看看我们如何处理这一部分。 所以这是我放在一起的 Faust JS 示例项目。 这很简单。 它基于 Faust 脚手架蓝图，但有一些额外的配置来处理这些块。

因此，如果我们看一下 JSON 包，您会发现这里有一些依赖项，一些常用的 Faust 包，例如核心和 CLI。 我们还有 Faust VP Blocks。 所以这是提供我们所有辅助功能的包之一。

我们在 WordPress 上也有一些用于处理样式等的依赖项。 您还会在这里注意到我们有这个 WP Blocks 目录。 所以这是我们前端的所有块所在的地方，并充当我们在前端使用的所有块的注册表。

你可以看到我们有一个 index.js 文件。 这本质上是一个对象，它决定了我们在前端使用的所有块。 所以你可以在这里看到，我们有核心段落、核心栏目、核心栏目和核心图像。

在设置方面，我们将讨论两个主要部分。 一个是 WordPress Blocks 提供者，一个是 WordPress Blocks 查看器。 因此，让我们看一下它的实际效果。 让我们首先看一下 WordPress Blocks 提供程序。

这将在 pages_app 中可用。 所以你可以在这里看到我们有这个组件，这个提供者，WordPress Blocks 提供者。 它接受一个接受块的配置道具。 所以你可以在这里看到我们从 WP Blocks 导入块，这个目录的索引，我们将它传递到配置对象中。

所以本质上，这就是说 WordPress Blocks 提供程序包装了您的整个应用程序，并为您的整个应用程序提供了所有这些块的上下文。 现在，让我们进入 WP Templates 进入我们的单一模板。 你可以在这里看到我们用内容块的支持调用 WordPress Blocks 查看器。 所以这是我们从 WPGraphQL 得到的块数据。

好吧，设置就够了。 让我们把它旋转起来，看看它的实际效果。 所以我要运行 NPM run dev，这将在 localhost 3000 上设置一个开发环境。我们之前处理的页面是斜杠示例页面，所以我将访问 localhost 3000 斜杠示例页面以查看那些 Gutenberg我们之前设置的块。

所以你可以在这里看到，我们的 Gutenberg 编辑器中有相同的块。 因此，让我们回到示例页面的 Gutenberg 编辑器。 你可以看到我们在这里有两列，这是我的段落，然后是我们的图像，它对应于我们在前端的图像。

所以你可能会说，这看起来很棒，但是我们可以修改样式吗？ 我们可以更改字体大小吗？ 你当然可以。

因此，让我们回到我们的古腾堡编辑器，对这些块进行一些修改。 所以让我们在这里为我们的段落添加背景颜色。 让我们也将大小更改为大。 对于这里的这张图片，让我们把它弄圆。

让我们把标题去掉。 我们会更新它。 你可以在这里看到这些样式现在适用。 您可以在前端看到它们。

因此，我们真正将您在 WordPress 中不期望的发布者体验返还给您的无头 WordPress 网站。 另一件很棒的事情是，现在您可以获得这些块的编程数据，您可以使您的 React 组件具有特定于框架的功能，如下图所示。 现在，我们不仅可以渲染从 WPGraphQL 返回的 HTML，还可以使用该编程数据来创建一个组件，该组件将我们在古腾堡中的所有图像与下一张图像一起渲染，从而为我们提供延迟加载、更好的性能和更好的优化图像总体而言，为我们的用户创造更好的用户体验。

所以这很棒。 我们在 Gutenberg 编辑器中看到的正是我们所期望的，但假设我们添加了一个可能不受支持的组件，或者我们尚未在 Faust 站点中配置的组件。 因此，让我们继续在这里创建一个新组件。 我们将使用表。

我们将做两行——第 1 行，第 2 行。去更新它。 如果我们在这里回顾我们的代码，我们可以看到我们已经定义了四个块——核心段落、核心栏、核心栏和核心图像。 我们这里没有核心表。

那么当我们查看这个页面时会发生什么呢？ 让我们来看看。 所以我们将返回 Faust 前端的示例页面。 你可以看到我们仍然在这里得到一个包含第 1 行和第 2 行的表格。

那是因为如果您的 Faust JS 项目中尚未定义该块，我们将对呈现的 HTML 进行明智的智能回退。 这样，您就不会看到未定义的、空的或根本没有内容。 至少，您将取回原始呈现的 HTML。

考虑到所有这些，让我们来看看创建一个块实际上需要什么——它实际上是什么样子的。 所以我们将在这里回到 VS Code。 让我们以核心图像为例。

所以你可以在这里看到，这只是一个传统的 React 组件。 我们称之为核心形象。 它接受道具，就像任何其他 React 组件一样。

这里基本上有两块。 所以我们得到了实际的 React 组件，它是表示层。 然后我们得到 block.fragments，这是这个块执行所需的数据。

所以你可以在这里看到我们正在创建一个片段，核心图像上的核心图像片段。 我们得到了这些属性——我们需要渲染这个块的属性。 所以你可以看到我们得到了替代文本、来源、标题、类名、宽度、高度等等。

然后我们可以做的就是将这些属性应用到我们实际的 React 逻辑中。 因此，此处请求的所有字段都可以在 props 中使用。 所以可以看到props.attributes出来了，就是我们这里请求的属性，attributes.alt，attributes.source等等。 因此，这是将块的所有数据要求集中在同一个文件中的好方法。

这是确保您只请求您需要的数据，并确保您的请求良好且高效。 在这个示例项目中，我们还有一些辅助函数。 你可以看到这里有一对——获取样式和获取图像大小的道具。

所以这些本质上只是从 WordPress 中获取这些样式，并将它们组合成 React 可以使用的实际样式对象。 目前，内联样式支持样式。 您也可以获得全局样式表，但我们目前正在努力为 theme.json 提供支持。

因此，Teresa 将在我们未来的路线图中谈及这一点。 但理想情况下，我们可以从 theme.json 获取所有样式和填充、边距等，并将其应用到无头前端。 考虑到所有这些，让我们与 Teresa 和我进行快速的技术讨论，谈谈我们目前在这个功能方面所处的位置，以及我们计划在未来发展的方向。

TERESA GOBBLE： 谢谢你的演示，Blake。 那很棒。 现在让我们继续讨论一些技术细节，并谈谈它是如何工作的。 所以我为您准备的第一个问题是，使用 WPGraphQL 内容块的要求是什么？

布莱克威尔逊： 是的，是的。 好问题，特蕾莎。 因此，使用该插件的唯一要求是同时安装 WPGraphQL。 显然，如果你想让你的站点与 Faust JS 交互，你可以安装 Faust JS blocks 包，这将有助于促进渲染和无头前端的所有好东西。 但是要真正公开块数据，您只需要 WPGraphQL 和 WP GraphQL Content Blocks 插件。

特蕾莎·戈布尔：太棒了。 区块数据又是如何收集的？

BLAKE WILSON：是的，所有块数据都由 WordPress 中使用寄存器块类型功能的任何块收集。 因此，几乎任何您正在使用该功能接口的块都会显示在内容块中。 最棒的是它与 block.json 文件进行中继，并自动对所有这些字段进行自我描述和自我记录。 因此，您将文档合而为一。

特蕾莎·戈布尔：哦，太棒了。 多么节省时间。 另一件我希望你多谈一点的事情是不受支持的块会发生什么？ 查询不受支持的块时会发生什么？

BLAKE WILSON： 是的，这是另一个很好的问题。 这里可能会发生两种真实情况。 因此，可能存在这样一种情况，假设您的帖子数据中有一个块，该块已从 WordPress 中删除。

也许是已删除的第三方块。 所以这是一个不受支持的块的例子，它在 Faust 前端和 WordPress 注册表中都不受支持。 在那种情况下，我们实际上将一个块返回到称为未定义块或未知块的内容块，以便您可以在无头前端中适当地键入它。 然后第二部分是如果支持 WordPress 注册表中的块，但它在您的 Faust JS 前端尚不支持，在这种情况下，我们所做的就是回退到呈现的 HTML。 这样，至少，您已经呈现了显示的 HTML，而不是 null 或 undefined 或任何类似的值。

特蕾莎·戈布尔：哦，太棒了。 这实际上引出了我的下一个问题。 至于无头分离网站中的第三方插件，您可以通过使用 WPGraphQL Content Blocks 插件来使用第三方插件吗？ 所有这些如何协同工作？

布莱克威尔逊： 是的，是的。 因此，对于任何第三方插件，回到第一个或第二个问题，只要它们与 WordPress 中注册的块类型功能交互，该块就会自动暴露给 WPGraphQL 内容块。 因此，只要正在呈现该数据，您就可以在 Faust JS 前端创建块。 最棒的是假设你有一个轮播的第三方块。 一旦您在 Faust JS 前端创建了它，您就可以在以后的其他项目中重用它。

特蕾莎·戈布尔：哦，太好了。 这就是可重用性部分的用武之地。有了这个插件，您实际上可以弥补第三方插件与解耦网站无法开箱即用的差距。

此外，如果您现在查看聊天，我们实际上已经构建了一个教程来帮助人们从第三方插件创建一个块。 所以你现在查看聊天，你将能够看到它并点击它。 给它一个书签。

那么如何处理块中的块呢？ 这真的很棘手。 你能和我们谈谈那会是什么样子吗？

布莱克威尔逊： 当然，是的。 所以当您查询名为 flat 的内容块时，我们有这个标志或这个参数。 并且接受真值或假值。 因此，当它被提供为 true 时，您实际上会得到该页面上所有块的平面数组或平面列表，无论它是列、图像还是段落。

您将获得在该页面上查询的所有块的完整列表以及两个附加属性。 一个是节点 ID。 这就是那个特定块的实际 ID。 然后您还将拥有父 ID，它是该块的父 ID。 所以你可以做的是在你的前端将它重建成一个实际的层次列表，几乎解决了我们之前在古腾堡看到的内部块难题。

特蕾莎·戈布尔：太棒了。 所以实际上，有一个选项，在获取内容块时，您可以指定在其适当的父子 ID 中返回块的平面列表？

BLAKE WILSON： 是的，没错。

特蕾莎·戈布尔：太好了。 实际上，我们在聊天中还有另一篇教程，同样，WPGraphQL 内容块也可以查看该特定功能。 所以我想问你另一个关于样式部分的问题——使用全局样式表、内联样式，那里的方法是什么？ 样式是如何处理的？

布莱克威尔逊： 是的，是的。 因此，造型可能是我们目前正在努力研究的最大推动力之一。 在我刚刚展示的示例中，它使用了内联样式。

全局样式，也支持全局样式表。 我认为您将在路线图中接下来谈到这一点。 但理想情况下，我们还希望支持 theme.json 支持，我们可以从 theme.json 中获取边距、填充、颜色和所有有用的信息，然后应用它们。 因此，我们将在下一阶段的开发中致力于此。

特蕾莎·戈布尔：太棒了。 感谢您引导我们完成这些。 我知道很多人对此感到非常兴奋。 那么我们如何限制发布者使用不支持的块呢？

布莱克威尔逊： 是的，是的。 所以那里有一个插件。 这取决于。 如果您使用第三方块，其中一些已经内置了此功能。

但如果没有，那里有一个称为块可见性的插件，您实际上可以从发布者的角度切换特定的块。 因此，假设您有一个尚未在您的 Faust 站点上实施的轮播块。 您可以安装块可见性，并取消选中它，以便发布者在它仍不受支持或处于开发阶段时不会使用它。

特蕾莎·戈布尔：哦，太棒了。 这样插件块可见性实际上可以切换、隐藏、显示特定块？

BLAKE WILSON： 是的，没错。 这样一来，您所支持的块数量有限，无论是在您的 WordPress 端还是在您的无头站点中，以便发布者知道，好的，我们可以肯定地使用它，它将在前端。

TERESA GOBBLE：哦，这听起来确实更干净。 嗯不错。 最后一个问题。 这些前端块是否对应于发布者的编辑器？

BLAKE WILSON： 是的，非常棒的标注。 所以还没有。 这是我们将来要努力的事情，但目前，无头前端支持这些块。

如果您有一个在 WordPress 中创建的自定义块，如果您使用的是 NPX 创建块命令，则您仍然需要在 WordPress 端支持该视图。 但这是我们正在努力的事情。 我们已经在我们的路线图中得到它。

特蕾莎·戈布尔：哦，太棒了。 好的。 布莱克，感谢您与我们讨论这些要点。 这真的很有帮助，演示也是如此。

让我们继续换档，实际多谈谈该项目路线图。 我们实际上有五个阶段，其中两个已经完成——阶段 1 和阶段 2。阶段 1，我们看到了一种方法的实现，可以有效地解构然后重建一个块。

之后，我们进入了第 2 阶段，重点关注 Faust 与 Gutenberg Blocks 的更紧密集成，以确保人们可以访问其中的不同实用程序和辅助功能。 我们实际上正在进入下一阶段，即第 3 阶段，我们专注于提供 theme.json 支持和可重用的块库，正如 Blake 在我们的技术讨论中提到的那样。

完成后，将进行第 4 和第 5 阶段。 第 4 阶段的重点是增强现有的开发和编辑体验，第 5 阶段的重点是支持核心 WordPress 之外的更广泛的生态系统。 我们对即将到来的这些阶段感到非常兴奋，我们希望您能与我们联系并查看我们的博客文章，以了解最新的路线图。

如果您看一下，您可以在下面的聊天中看到指向我们博客文章的链接。 继续并为它们添加书签。 好吧，谢谢大家加入我们对 React-Gutenberg Bridge 的讨论。 我想在这里让 Blake 回到屏幕上，这样他也可以表达他的谢意，并向我们提供更多信息，告诉我们如果您在此之后有任何挥之不去的问题可以去哪里。

BLAKE WILSON： 是的，谢谢 Teresa，感谢今天参加本次会议并观看的所有人。 我们很高兴收到一些关于此功能的社区反馈，以便大家开始尝试。

因此，如果您喜欢它，我们在聊天链接中提供了示例项目。 我们在无头 Discord 的聊天中也有一个链接，因此您和其他志同道合的无头开发者可以加入并讨论无头空间中即将推出的功能和版本。 再次感谢大家。 我们真的很感激。