Gatsby 宣布其新的 WordPress 源插件（ v4) 现在处于测试阶段。该插件已经过大修，以改进 Gatsby 为前端提供动力的无头 WordPress 设置。它还与 Gatsby Cloud 一起提供实时预览和增量构建。
Gatsby 团队在为 WordPress 网站创建可满足更复杂用例的集成方面取得了长足的进步。目前，有 3 种方式将 Gatsby 与 WordPress 相结合，各有优缺点：
- Gatsby source WordPress + WP REST API
- Gatsby source GraphQL + WPGraphQL
- Gatsby source WordPress (v4) + WPGraphQL
第一种方法依赖WP REST API获取所有数据（posts, terms, media等）缓存在Gatsby 的节点缓存。第二种方法允许开发人员编写 GraphQL 查询以从 Gatsby 缓存中获取数据并在模板中呈现该数据。
根据 Gatsby 工程师和 WPGraphQL 的创建者 Jason Bahl 的说法，前两种方法仅适用于基本用例。
“当您开始添加更多高级功能（例如高级自定义字段 Flex 字段）时，WP REST API 开始崩溃并变得难以以解耦的方式使用，”Bahl 说。 “WP REST API 有一个架构，该架构可以允许插件和主题扩展 WP REST API 并声明任何给定端点将公开的数据类型。这有助于解耦的应用程序提前知道期望的数据。
“问题”即插件和主题可以在不使用 Schema 的情况下扩展 WP REST API，或者只需将 Schema 中的字段类型定义为对象类型或数组类型。这意味着要解耦包括 Gatsby 在内的应用程序，没有简单的方法可以知道从这些字段中可以得到什么。Gatsby 依赖于一致的数据，而 WP REST API 是不一致的。从端点返回的数据的形状（尤其是当插件扩展了 REST API）是不可预测的，这对于分离的应用程序来说是一个问题。”
WPGraphQL 是 WP REST API 的替代品，它通过其强制架构解决了许多这些痛点。这极大地有利于解耦工具，例如 Gatsby，因为它们可以在请求任何数据之前进行内部检查以确定哪些数据可用。
“因此，即使在高级自定义字段弹性域的情况下，返回的数据也可以是在许多可能的弹性域布局中，Gatsby 仍然可以在请求之前知道哪些数据是可能的，”Bahl 说。“WPGraphQL 的强制架构使解耦工具能够自信地交付并消除所有类型的错误。”
Gatsby Source GraphQL + WPGraphQL 方法提供了一些使用 WP REST API 的改进，但限制在于它不会将数据缓存到 Gatsby 节点缓存中。这会阻止 WordPress 站点利用 Gatsby 云的商业产品进行预览和增量构建。 Bahl 解释了新的 Gatsby Source WordPress 插件 (v4) + WPGraphQL 如何“两全其美”：
新的集成使内容创建者能够单击“预览”以实时查看他们的更改在 Gatsby 支持的站点中。发布不再需要完整的站点重建。它只会将更改推送到受影响的页面。更改将在几秒钟内完成，类似于用户如何期望 WordPress 在没有无头集成的情况下工作。新插件与 Gatsby Cloud 配合使用，可以更好地将内容创建体验与 Gatsby 的 React + GraphQL 开发人员体验相结合，同时提供快速的静态页面。
如果您想测试新的 Gatsby Source WordPress 插件的测试版，您可以在 GitHub 上找到它（及其依赖项）。还需要 WPGraphQL 和 WPGatsby 插件。
像这样：喜欢正在加载...
资源
