Gutenberg 区块编辑器文档

title: "模块化" post_status: publish comment_status: open taxonomy: category: - gutenberg-docs post_tag: - Architecture - Explanations - Repos

模块化

WordPress 区块编辑器基于这样的理念：你可以将独立的区块组合在一起来撰写文章或构建页面。区块之间也可以相互使用和交互。这使得它非常模块化和灵活。

但区块编辑器不仅在行为和输出上采用模块化。Gutenberg 代码库本身也是由多个可复用且独立的模块（或称包）构建而成，这些模块组合在一起，形成了我们所熟知的应用和界面。这些模块被称为 WordPress 包，并在 npm 包仓库中定期发布和更新。

这些包不仅用于驱动区块编辑器，也可用于驱动 WordPress 后台或外部的任何页面。

为何采用模块化架构？

采用模块化架构对所有参与者都有多重益处：

包的类型

Gutenberg 仓库中的几乎所有内容都被构建成包。我们可以将这些包分为两种不同类型：

生产包

这些是随 WordPress 本身作为 JavaScript 脚本发布的包。它们构成了在浏览器中运行的实际生产代码。例如，有一个 components 包，作为可复用的 React 组件集，用于快速原型设计和构建界面。还有一个 api-fetch 包，可用于调用 WordPress Rest API。

第三方开发者可以通过两种不同的方式使用这些生产包：

npm install @wordpress/components

import { Button } from '@wordpress/components';

function MyApp() {
    return <Button>Nice looking button</Button>;
}

// myplugin.php
// 依赖于 "components" 和 "element" 包的脚本注册示例。
wp_register_script( 'myscript', 'pathtomyscript.js', array ('wp-components', "react" ) );

// 在你的脚本中使用包
const { Button } = wp.components;

function MyApp() {
    return <Button>Nice looking button</Button>;
}

对于开发者来说，定义脚本依赖项可能是一项繁琐的任务。错误和疏忽很容易发生。如果你想了解如何自动化此任务，请查看 @wordpress/scripts 和 @wordpress/dependency-extraction-webpack-plugin 文档。

包含样式表的软件包

某些生产环境软件包需要样式表才能正常运行。

在现有 WordPress 页面环境中，若未正确定义脚本或样式依赖项，当这些脚本和样式已由 WordPress 或其他插件加载时，您的插件可能仍能正常工作。但强烈建议详尽定义所有依赖项，以避免未来版本可能出现的故障。

包含数据存储的软件包

部分 WordPress 生产软件包定义了用于处理状态的数据存储。这些存储也可被第三方插件和主题用于检索和操作数据。这些数据存储的名称同样遵循 core/软件包名称 的格式进行规范化（例如，@wordpress/block-editor 软件包定义并使用了 core/block-editor 数据存储）。

若您在插件中使用这些存储来访问和操作 WordPress 数据，请务必将对应的 WordPress 脚本添加至您插件的脚本依赖中，以确保插件正常运行。（例如，若您从 core/block-editor 存储中检索数据，则应如上文所示，将 wp-block-editor 软件包添加至您的脚本依赖中）。

开发包

这些是在开发模式下使用的包，旨在帮助开发者完成日常任务，包括开发、构建和发布 JavaScript 应用、WordPress 插件和主题。它们包含用于代码库检查、构建和测试的工具。

编辑器包

文章编辑器模块架构

不同编辑器包之间有什么区别？每个包的用途是什么？

新贡献者常常惊讶地发现，文章编辑器是由三个独立包 @wordpress/edit-post、@wordpress/editor 和 @wordpress/block-editor 的分层抽象构建而成。

上面的为什么？部分应该解释了各个包如何旨在满足特定需求。这也适用于这些包：

通过这种结构，这些包可以在“新建文章”屏幕用例之外的各种组合中使用：

深入探索