| 前端插件化架构的探索和实践（上篇） | 您所在的位置：网站首页 › 插件模式架构是什么 › 前端插件化架构的探索和实践（上篇） |
前端插件化架构的探索和实践（上篇）
|
本文是azuo和萌妹俩的第一篇创作，内容创作@azuo😄，精神支持@大头萌妹😂 前言：babel插件、webpack插件、vue CLI插件，为啥这么多的优秀框架都是使用插件系统？插件化架构是什么？带来了什么好处？可以应用到什么场景呢？ 一、插件化架构定义插件化架构又称微核架构，指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。插件化架构一般有两个核心的概念：内核和插件。 内核（pluginCore）通常只包含系统运行的最小功能； 插件（plugin）则是互相独立的模块，一般会提供单一的功能。内核除了插件的管理功能，还会将要完成的所有业务进行抽象，抽象出最小粒度的基础接口，供插件方来调用。这样，插件开发的效率将会极大的提高。比方说，浏览器就是一个典型的插件化架构，浏览器是内核，页面是插件，这样通过不同的URL地址加载不同的页面，来提供非常丰富的功能。而且，我们开发网页的时候，浏览器会提供很多API和能力，这些接口通过 window来挂载， 比如，DOM、BOM、Event、Location等等。 设计一个完善的插件化架构的系统，包含三要素： plugCore：插件内核，提供插件运行时，管理插件的加载、运行、卸载等生命周期（类比浏览器）； pluginAPI：插件运行时需要的基础接口（类比浏览器例子，相当于window）； plugin：相互独立的模块，提供了单一的功能（类比浏览器例子，相当于不同的网页）。我们将从plugCore、 pluginAPI和plugin三要素的视角，来解析jQuery、Babel和Vue CLI这三大优秀的开源库其插件化架构的实践。 2.1 jQuery的插件化架构jQuery 是一个 JavaScript 库，极大地简化了JavaScript 编程，用更少的代码完成更多工作。早期浏览器的标准不统一，开发网页需要兼容不同浏览器的用户使用是一件十分痛苦的事情。jQuery在适配了不同浏览器的差异的基础上提供了更加完善易用API，供前端开发人员完成网页编程，使用jQuery编写的网页，在一套代码下也可以在不同厂商的浏览器上正常运行。在 MV* 框架流行之前，jQuery是绝对的扛霸子。jQuery是可扩展的，其拥有完善的插件体系，网页开发所需要的各种插件在其生态都可以找到。我们解析一下jQuery插件体系。 插件定义：特别说明：$.fn = jQuery.protype(插件精髓)。jQuery的插件机制通过原型链来挂载。 插件机制执行过程
Babel 是一个工具链，主要用于将 ECMAScript 2015+ 版本的代码转换为向后兼容的 JavaScript 语法，以便能够运行在当前和旧版本的浏览器或其他环境中。在代码转换的过程中会涉及许多特性和语法的转换，而且ECMAScript的提案总是不断地更新。如何组织大量（不断增加）的转换规则呢？我们来看看 Babel的工作原理 Babel转换源码，分为三个步骤： 解析（parse）： 进行词法分析（Lexical Analysis）和语法分析（Syntactic Analysis）以生成抽象语法树（AST）； 转换 (transform)： 遍历AST中所有节点并进行相应的转换操作，该过程使用不同的插件来完成各种特性和语法的转换； 生成 (generate)： 根据转换后AST生成目标代码。Babel在AST转换的过程（即上图的第2步）使用的就是插件化架构。下面将会详细讲解这个转换过程的插件化架构的使用。 插件定义： // 精简版 export default function (pluginApi, pluginOtpions) { return { name: '插件名', visitor: { enter(nodePath) { }, // 每个节点在进入时调用 exit(nodePath) { }, // 每个节点在离开时调用 [NodeType](nodePath) { }, // nodePath.type === NodeType时执行 } } } 复制代码插件是一个函数，返回值是一个包含visitor的对象。插件定义的部分概念说明： name： 插件名 pluginAPI: 插件运行时传入的API visitor: 是一个对象，对象的key是节点的类型，对象的值是一个函数，AST转换的过程便在这里发生的。 nodePath：是一个AST的节点的实例对象，详细可以参考：@babel/parser/src/parser/node.js，其中，type字段：节点的类型，AST遍历是根据节点Type来寻找visitor来实现转换的。常见类型：VariableDeclaration（变量声明）、ArrowFunctionExpression（箭头函数表达式）等等，详细可以参考@babel/types。（笔者认为pluginAPI还应包括nodePath，因为，每个节点实例除了语法和词法描述，还包含需求语法间的转换方法） 插件示例箭头函数转换成普通函数的插件：@babel/plugin-transform-arrow-functions源码： import { declare } from "@babel/helper-plugin-utils"; import type NodePath from "@babel/traverse"; export default declare((api, options) => { api.assertVersion(7); const { spec } = options; return { name: "transform-arrow-functions", visitor: { ArrowFunctionExpression( path: NodePath, ) { // In some conversion cases, it may have already been converted to a function while this callback // was queued up. if (!path.isArrowFunctionExpression()) return; path.arrowFunctionToExpression({ // While other utils may be fine inserting other arrows to make more transforms possible, // the arrow transform itself absolutely cannot insert new arrow functions. allowInsertArrow: false, specCompliant: !!spec, }); }, }, }; }); 复制代码插件的执行思路： 第一步，执行该插件，获取到包含visitor对象； 第二步，ATS遍历节点，检测nodePath的type === 'ArrowFunctionExpression'，寻找到vistor对象的中key为 ArrowFunctionExpression的函数； 第三步，将nodePath传入该函数进行调用（AST在这步被修改）； 单个插件的执行思路很明确了，那么在ATS遍历过程，怎么做到多个插件一起工作呢？ Babel在转换源码过程中，插件化架构的工作流程是这样的： 第一步：通过解析babel的配置文件（或者命令行--plugins参数），获取Babel配置的所有插件的描述； 第二步，将插件的require进内存，获得插件函数，并执行插件函数，获取到多个包含vistor字段对象；（详细逻辑：@babel/core/src/config/full.js） 第三步，将多个包含vistor字段对象整合成一个大的visitor（详细逻辑：@babel/core/src/transformation/index.js）
visitor的对象中的值由单个函数变成了**Array {} 复制代码 prompts.js：安装时候询问用户对其插件的选项配置，内部是通过 inquirer 实现，被调用后获得选项配置，并在 generator.js调用时作为参数存入； // 导出模块定义 module.exports = [ { type: 'input', name: 'locale', message: 'The locale of project localization.', validate: input => !!input, default: 'en' } ] 复制代码 index.js：Service插件的入口，@vue/cli-service 启动时被执行 // 导出模块定义 module.exports = (pluginApi, options) => { // 修改webpack配置 api.chainWebpack(webpackConfig => {}) } 复制代码 更加详情可以去看Vue Cli 插件开发指南 我们把Vue CLI的插件执行分成两种情况： 第一种：插件未安装，插件被安装的时候调用（prompts.js + generator.js） 第二种：插件已安装，插件系统启动时被执行（index.js） 第一种 安装流程相比Babel的手动安装添加插件方式，Vue CLI的插件系统提供命令行的安装方式就显得很方便了。我们看看Vue Cli插件系统时怎么实现一行命令添加插件的功能。 安装流程的执行思路如下： 第一步：从命令行参数解析出插件名，然后通过npm i vue-cli-plugin-xxx 安装插件，源码位置：@vue/cli/lib/add.js 第二步：require('vue-cli-plugin-xxx/prompts'),并获取用户安装是选项结果pluginOptions，源码位置：@vue/cli/lib/invoke.js // 代码精简过 const prompt = inquirer.createPromptModule() const pluginPrompts = require(`vue-cli-plugin-xxx/prompts`) const pluginOptions = await prompt(pluginPrompts) 复制代码 第三步：使用pluginName和pluginOptions作为参数构成出Generator对象的实例 // 代码精简过 const plugin = { id：'vue-cli-plugin-xxx', options: { ...pluginOptions } } const generator = new Generator(context, { plugins: [plugin], invoking: true }) 复制代码第四步：执行generator.generate方法。这步包括了三个关键步骤： 1）require(vue-cli-plugin-xxx/generator)，获得插件的执行函数； 2）构建GeneratorAPI（即pluginAPI）； 3）调用generator.js导出函数。 // 代码精简过 const apply = require(`vue-cli-plugin-xxx/generator`) const pluginApi = new GeneratorAPI(id, pluginOptions) await apply(pluginApi, pluginOptions) // pluginOptions为第二步获得选项结果 复制代码详细代码：@vue/cli/lib/Generator.js 第五步：将插件名和插件的参数添加到vue.config.js文件中。 第二种 运行流程插件运行流程是由@vue/cli-service 这个插件系统定义的，这里的调用插件有两种： 第一种 内置插件（@vue/cli-service的命令和配置相关，将系插件统功能拆分出多个内置插件，在插件系统中默认调用）； 第二种 项目插件，（package.json 中定义的npm包名符合插件命名规范）。插件运行逻辑很简单：
这两个流程的 pluginAPI是不一样的。 - 安装流程：@vue/cli/lib/GeneratorAPI - 运行流程：@vue/cli-service/lib/PluginAPI.js 从三要素来总结：1）安装流程 pluginCore：@vue/cli通过命令行参数获得插件包名，然后安装插件的npm包，并执行prompts.js 获得用户安装选项结果，然后，使用选项结果和generator.js作为参数构造出generator，并在调用generator.generate中执行generator.js函数； pluginAPI：GeneratorAPI，提供了源码修改、npm包管理、模版文件生成等功能； plugin：prompts.js和generator.js，解决某种能力植入项目时，要处理的依赖。 2）运行流程 pluginCore：@vue/cli-service，通过package.json中获得项目插件后，与系统内置插件合并，最后依次执行； pluginAPI：PluginAPI，提供webpack配置修改和命令管理的能力； plugin：index.js文件，在不同命令下进行工作。 一个插件系统可以包含多种插件实现方式，并且插件系统通过命令安装插件的实现，对用户使用插件系统也是十分方便的。 三、插件化架构的应用 3.1 应用场景通过上述的实例，总结处理插件架构的应用场景。 第一种：富pluginAPI场景：代码在多种场景中运行，需要抹平场景中差异（jQuery）； 第二种：富plugin场景，插件系统，可预期需求会越来越多，适合通过更多的插件来简化系统的代码量（Babel） 第三种：富pluginCore和pluginAPI场景，系统本身非常复杂，对开发人员要求极高，这时候，使用插件化架构，将其复杂的工作放到pluginCore和中pluginAPI实现，剩下大部分的简单的编码工作留给插件方实现，插件方借助pluginAPI也可以快速完成业务开发（Vue CLI） 3.2 发展的方向通过建立一个插件标准，将研发流程沉淀的能力进行插件化编程，整个公司通过使用一套的插件系统（中台），这样意味着，我们不用重复造业务轮子，团队和企业可以持续积累自己的插件生态，让软件开发可以像汽车等工业制造一样，打造一条标准化装配的流水线。 （下篇将讲述插件化与其他架构结合使用，以及三要素如何调优，欢迎关注，下回讲解） |
【本文地址】