Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the front-end plug-in architecture", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "what is the front-end plug-in architecture"!

1. Plug-in architecture definition

Plug-in architecture, also known as microkernel architecture, means that the kernel of the software is relatively small, and the main functions and business logic are implemented through plug-ins. Plug-in architecture generally has two core concepts: kernel and plug-in.

The pluginCore usually contains only the minimum functions that the system is running.

Plug-ins (plugin) are independent modules and generally provide a single function.

The kernel will generally abstract all the services to be completed, abstracting the basic interface with the smallest granularity for the plug-in side to call. In this way, the efficiency of plug-in development will be greatly improved. For example, the browser is a typical plug-in architecture, the browser is the kernel and the page is the plug-in, so that different pages are loaded with different URL addresses to provide very rich functionality. Moreover, when we develop web pages, browsers provide a lot of API and capabilities, which are mounted through window, such as DOM, BOM, Event, Location, and so on.

Design a perfect plug-in architecture system, including three elements:

PlugCore: plug-in kernel, providing plug-in runtime, managing plug-in load, run, unload, etc. Life cycle (analogy browser)

PluginAPI: the basic interface required by the plug-in runtime (analogous browser example, equivalent to window)

Plugin: a series of independent modules for specific functions (analogous to browser examples, equivalent to different web pages).

two。 The practice of plug-in Architecture

We will analyze the practice of plug-in architecture of three excellent open source libraries: jQuery, Babel and Vue CLI from the three elements of plugCore, pluginAPI and plugin.

2.1 plug-in architecture of jQuery

JQuery is a JavaScript library that greatly simplifies JavaScript programming and does more work with less code. The standards of early browsers were not uniform, and it was very painful to develop web pages that needed to be compatible with users of different browsers. On the basis of adapting to the differences of different browsers, jQuery provides a more perfect and easy-to-use API for front-end developers to complete web page programming, and web pages written with jQuery can also run normally on browsers of different manufacturers under a set of code. Before the popularity of the MV* framework, jQuery was an absolute bully. JQuery is extensible, it has a perfect plug-in system, and all kinds of plug-ins needed for web development can be found in its ecology. Let's analyze the jQuery plug-in system.

Plug-in definition:

Special note: $.fn = jQuery.protype (plug-in essence). The plug-in mechanism of jQuery is mounted through the prototype chain.

Plug-in mechanism execution process

Demo example

$app can find myPlugin on the prototype chain:

To sum up from the three elements:

PluginCore: extend different plug-ins through prototype chain assignment, and then get a jQuery instance that can be called.

The core interface of the pluginAPI:jQuery package, (jQuery wins with its excellent Api)

Plugin: unlimited, can be the type of JavaScript, generally a module that implements specific functions, such as a date selector, etc.

2.2 plug-in architecture of Babel

Babel is a chain of tools that is primarily used to convert code from the ECMAScript 2015+ version into a backward-compatible JavaScript syntax so that it can run in current and older browsers or other environments. Many features and syntax transformations are involved in the transcoding process, and ECMAScript's proposals are constantly updated. How do you organize a large (and increasing) number of conversion rules? Let's take a look at how Babel works.

Babel converts the source code in three steps:

Parsing (parse): performing lexical analysis (Lexical Analysis) and syntactic analysis (Syntactic Analysis) to generate an abstract grammar tree (AST)

Transform: traverses each node in the AST and performs the corresponding conversion operation, which converts various features and syntax by using different plug-ins

Generate: generates the object code based on the AST.

Babel uses the plug-in architecture during the AST transformation process (that is, step 2 of the figure above). The use of the plug-in architecture for this conversion process will be explained in detail below.

Plug-in definition:

The plug-in is a function and the return value is an object containing visitor. Part of the concept description of the plug-in definition:

Name: plug-in name

PluginAPI: the API passed in by the plug-in runtime

Visitor: is an object, the key of the object is the type of each node of the AST, the value of the object is a function, and the process of AST conversion takes place here.

NodePath: is an instance object of an AST node. For more information, please see @ babel/parser/src/parser/node.js [1], where type field: the type of the node, common types: VariableDeclaration (variable declaration), VariableDeclarator (variable declaration expression), ArrowFunctionExpression (arrow function expression), etc. For more information, please see @ babel/types [2].

(the author thinks that pluginAPI should also include nodePath, because each node instance not only contains syntax and lexical description, but also contains the conversion method between requirement syntax.)

Plug-in example

Plug-in for converting arrow functions into ordinary functions: @ babel/plugin-transform-arrow-functions [3] source code:

The execution idea of the plug-in:

The first step is to execute the plug-in to get the object containing the visitor

In the second step, ATS traverses the node and detects the type of nodePath = = 'ArrowFunctionExpression', to find the function in the vistor object where key is ArrowFunctionExpression

The third step is to pass nodePath into the function to call (AST is modified at this step)

The execution idea of a single plug-in is clear, so how can multiple plug-ins work together in the ATS traversal process?

During the Babel source code conversion process, the workflow of the plug-in architecture is as follows:

Step 1: get the descriptions of all plug-ins configured by babel by parsing the Babel configuration file (or the command line-- plugins parameter)

The second step is to put the require of the plug-in into memory, get the plug-in function, and execute the plug-in function to get multiple objects containing vistor fields; (detailed logic: @ babel/core/src/config/full.js [4])

Third, integrate multiple objects containing vistor fields into a large visitor source code presentation (detailed logic: @ babel/core/src/transformation/index.js [5]):

The merged visitor object:

The value in the object of visitor becomes Array

The fourth step, AST traversal, each node according to NodeType, to get visitor [NodeType], and in turn to execute.

To sum up from the three elements:

PluginCore: plug-ins load and integrate (that is, vistor merge). During AST traversal, find vistor [NodeType] is called and then called

PluginAPI:nodePath, which provides interfaces for different types of nodes to convert AST nodes

Plugin:visitor [NodeType] = function (nodepath).

2.3 plug-in architecture of vue-cli

Vue CLI is a complete system for rapid development based on Vue.js. CLI plug-ins are npm packages that provide optional features to your Vue project, such as Babel/TypeScript translation, ESLint integration, unit testing, and end-to-end testing. The name of the Vue CLI plug-in starts with @ vue/cli-plugin- (built-in plug-in) or vue-cli-plugin- (community plug-in), which is easy to use. Next, we will parse the definition, execution, installation, and so on of the cli plug-in.

Plug-in definition

The plug-in must be a vue-cli-plugin--named npm package, and the directory structure must be defined strictly according to file naming.

Note: @ vue/cli-service [6] will use the npm package that conforms to the plug-in naming convention in the npm package defined in dependencies and devDependencies in package.json under the project root directory as the plug-in for the project.

File naming and content description:

Generator.js: will be executed when the plug-in is added. You can install the npm package, modify the project source code and other functions.

Prompts.js: all the conversation logic is stored in the prompts.js file. The inner part of the conversation is implemented through inquirer [7], which is called to get the result of the installation option and stored as a parameter when generator.js is called.

The entry of the index.js:Service plug-in, @ vue/cli-service [8], is executed when it starts

For more information, please see the Vue Cli plug-in Development Guide [9]

We divide the plug-in execution of Vue CLI into two situations:

First: plug-ins are not installed and are called when plug-ins are added (prompts.js + generator.js)

Second: the plug-in has been installed and executed when the plug-in system is started (index.js)

The first installation process

Compared with Babel's manual installation and add plug-ins, Vue CLI's plug-in system provides command-line installation is very convenient. Let's take a look at how the Vue Cli plug-in system implements the function of adding plug-ins with one-line commands.

The implementation of the installation process is as follows:

Step 1: parse the plug-in name from the command line arguments, install the plug-in using npm (yarn) install vue-cli-plugin-xxx, source location: @ vue/cli/lib/add.js [10]

Step 2: require ('vue-cli-plugin-xxx/prompts'), and get the result pluginOptions of the option for user installation. Source location: @ vue/cli/lib/invoke.js [11]

Step 3: use pluginName and pluginOptions as parameters to form an instance of the Generator [12] object

Step 4: execute the generator.generate method. This step includes three key steps:

1) require (vue-cli-plugin-xxx/generator) to get the execution function of the plug-in

2) build GeneratorAPI (i.e. pluginAPI)

3) call the generator.js export function.

Detailed code: _ @ vue/cli/lib/Generator.js [113] _

Step 5: add the parameters of the plug-in to the vue.config.js file.

The second running process

The plug-in running process is defined by the @ vue/cli-service [14] plug-in system, where there are two kinds of calling plug-ins:

The first built-in plug-in @ vue/cli-service command is related to configuration, which splits the plug-in system function into multiple built-in plug-ins, which are called by default in the plug-in system)

The second project plug-in, the npm package name defined in package.json, conforms to the plug-in naming convention.

The plug-in running logic is simple:

The pluginAPI of the two processes is different.

Installation process: @ vue/cli/lib/GeneratorAPI [15]

Run the process: @ vue/cli-service/lib/PluginAPI [16]

At this point, I believe you have a deeper understanding of "which front-end plug-in architecture", you might as well to actually operate it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.