About plug-in mechanism - 关于插件机制

[sanyuan0704]

插件机制要解决是实际上是系统如何扩展的问题，那么我们可以把问题抽象成如何保证功能的扩展性足够好。

功能的扩展性主要拆分为两个阶段: 数据生产阶段 和 数据消费阶段。

举个例子，如果现在要添加一个指定代码行高亮的功能，我们可以在构建阶段添加一个 unified 插件，将 Mdx AST 进行转换，给相应行的 span 节点添加一个 highlight 的 className。然后在客户端加入对应 className 的样式代码，高亮的效果就实现出来了。

在如上的例子中，在编译 Mdx 的过程中添加 unified 插件属于数据生产阶段，这个阶段考虑的是如何处理数据源的问题，除了 Mdx 编译过程中之外，还包括约定式路由的生成、底层构建工具的行为，因此这几个部分的自定义能力需要对外透出。

而给客户端添加样式代码使新加的 highlight 类名生效，这一步发生在数据消费阶段，这个阶段主要需要做两件事:

• 拿到生产阶段提供的数据；
• 呈现数据，添加样式、交互等内容。

所以为了保证这个阶段的扩展能力，需要做如下的事情:

• 内核侧提供足够的数据接口，比如 usePageData、useThemeConfig 这类 Hook 充分暴露数据。
• 样式的定制接口。提供自定义样式的入口，如自动扫描styles下的样式文件并注入页面。
• UI 主题的定制接口。提供自定义主题的入口。

除了对外暴露这些原子之外，还需要考虑原子能力的组合和封装的问题，比如要实现代码行高亮功能，我们需要同时扩展 Mdx 编译和全局样式两个能力，有的功能涉及到的原子能力会更多，那这时候就需要支持不同原子能力的组合了，这种组合我们也可以称之为一个插件。所以对于文档框架而言，我们是需要插件机制的，而插件机制的作用，就是以功能的维度封装各个原子能力的组合。

从扩展性的维度来说，Island.js 目前主要存在两方面的问题：

• 部分原子能力的缺失。目前样式的定制、主题组件的定制都还没有正式支持，样式的自定义主要指的是全局样式的注入，而主题组件的自定义则是广义上的自定义主题，一方面要能自定义Layout组件，另一方面要保证默认主题的可继承，即暴露一系列的 slot 来让用户填充内容，大体的页面框架可以复用默认主题。
• 插件机制的缺失。插件可以理解为不同原子能力的组合，目前还没有提供这样的组合能力，需要进一步设计和完善。

近期的重点将会集中在原子能力的完善方面，支持全局样式的引入功能，同时进一步提升主题组件的可扩展性，提供一系列的 slot 接口，并完善自定义主题组件的文档和教程。

English Version:

The plug-in mechanism needs to solve the problem of how to extend, so we can abstract the problem into how to ensure the scalability of the function is good enough.

The scalability of functions is mainly divided into two stages: Data production stage and Data consumption stage.

For example, if we now want to add a feature to highlight specific lines of code, we can add a unified plugin in the build phase, convert the Mdx AST, and add a highlight className to the span node of the corresponding line. Then add the style code corresponding to className on the client side, and the highlighting effect is realized.

In the above example, adding a unified plug-in in the process of compiling Mdx belongs to the data production stage. This stage considers how to deal with the data source. In addition to the Mdx compilation process, it also includes the generation of conventional routes and the underlying construction. The behavior of the tool, so the customization capabilities of these parts need to be exposed to the outside world.

Adding style code to the client makes the newly added highlight class name take effect. This step occurs in the data consumption stage. There are two main things to do in this stage:

• Get the data provided in the production stage;
• Render data, add styles, interactions, and more.

So in order to ensure the scalability at this stage, the following things need to be done:

• Provide enough data interfaces on the kernel side, such as usePageData, useThemeConfig and other hooks to fully expose data.
• Styled custom interface. Provides an entry for custom styles, such as automatically scanning style files under styles and injecting them into pages.
• Custom interface for UI themes. Provides access to custom themes.

In addition to exposing these atoms to the outside world, we also need to consider the combination and encapsulation of atomic capabilities. For example, to implement the code line highlighting function, we need to expand the two capabilities of Mdx compilation and global style at the same time. Some functions involve atomic capabilities. There will be more, then you need to support the combination of different atomic capabilities, which we can also call a plug-in. Therefore, for the document framework, we need a plug-in mechanism, and the function of the plug-in mechanism is to encapsulate the combination of various atomic capabilities in the dimension of function.

In terms of scalability, Island.js currently has two main problems:

• Some atomic abilities are missing. At present, the customization of styles and the customization of theme components are not officially supported. The customization of styles mainly refers to the injection of global styles, while the customization of theme components is a custom theme in a broad sense. Define the Layout component, on the other hand, ensure the inheritance of the default theme, that is, expose a series of slots to allow users to fill in the content, and the general page framework can reuse the default theme.
• Lack of plugin mechanism. A plug-in can be understood as a combination of different atomic capabilities. Currently, there is no such combination capability, and further design and improvement are required.

In the near future, the focus will be on improving atomic capabilities, supporting the introduction of global styles, further improving the scalability of theme components, providing a series of slot interfaces, and improving documentation and tutorials for custom theme components.

[sanyuan0704]

#122