Looking at the front-end material ecology from the business component library

At present, the main energy is to maintain the business component library in the group. Of course, it also includes the blocks, templates, and solutions that we will expand in the future. This document mainly combines my past project experience and briefly introduces my understanding of the front-end material ecology.

First of all, in my opinion, the division of materials from the granularity of reuse is roughly divided into the following categories:

• Component
• Block
• Page template;
• Scenario-based solutions;

Component

As the smallest unit of front-end materials, components serve various business systems. In use, components can be provided to business systems in the form of component libraries/single packages, or they can serve a specific building system in accordance with a certain DSL protocol as a UI atom (UI visualization building system) / logical atom (logical orchestration system) ).

From the perspective of component architecture and composition form, components can be divided into single-package multi-component (component library) and single-package single-component.

Here is an example of antd: antd itself is provided to developers in the form of a single package and multiple components as a component library, and each component at the bottom of depends on a single package component in 161af29ad4aa7e react-component

The advantage of the single-package multi-component form is that the components are more aggregated and presented to users, and the common dependencies between components can also be better abstracted and reused. For users, one package can enjoy the resources of the entire package. But the disadvantage is that a small change also requires the entire component library to be packaged as a whole.

The advantage of the single-package single-component form is that the components see natural decoupling, and the components see independent release. The disadvantage is that because each component is completely physically isolated, it is necessary to extract more basic dependency packages to share for common dependencies. If single-package components have chain dependencies, each release is not a small challenge for component developers. Of course, it can also be solved to a certain extent through the MonoRepo architecture. In addition, if a component is large, logically heavy, and has a domain-specific reuse scenario, it can also be provided as a single component package, such as a rich text editor, a video player, etc.

From a functional point of view, our components can be divided into view-type components that focus on views and interactions and container-type components that focus on business logic.

Container component

Container-type components are often used to aggregate multiple display-type components and carry certain business logic: request interfaces, merge data, and so on. In the reuse of container components, we often use render props, HOC or more fine-grained hooks to achieve (the same is true for view components).

View component

View components can be further divided into UI components and business components from the use of business scenarios and the division of functions.

UI components

The first is the UI component. From a functional point of view, this type of component is mainly used as the smallest unit on the page to solve a certain type of , or in other words, this type of component is for a certain type of scene. Find the , such as Input, Select, etc., their biggest advantage is that high degree of multiplexing and flexible use of . But the shortcomings also come with it. The UI components that solve the single point scenario need to combine a large number of components and business logic to produce a front-end page.

UI components are generally a general paradigm that can satisfy most scenarios in the industry. The industry often uses these UI components with general characteristics in the form of component libraries for developers, such as AntD, ElementUI, Fusion, etc.

Business component

Although the UI component library has been able to meet most of the design and production requirements, it often has its own unique design language or component combination mode for specific scenarios and business domains. For middle and back-office teams with fast iteration speeds and many project engineering assets, it is obviously a waste of manpower for each project and team to deposit a set of component assets of the same business domain. The composition paradigm can then be precipitated in the form of a business component library.

For example, there are a large number of circle selection components for people, time, and regions in my current advertising lead, or common form linkage in the middle and backstage. These components are often UI components such as input and select plus certain business interaction logic and design. Standards, then we can precipitate them in the form of business components and business component libraries.

To sum up, UI components are to meet the general paradigm of most production scenarios, and business components are to meet the general paradigm of a specific business field. They are all to solve a single point scenario of the front-end page.

Block

Component dimensions have been able to meet most production scenarios, but for a fixed mode of interaction scenarios alone components still requires a lot of repetitive work in combination, so we have to solve by block a piece of content reuse issues.

In terms of use, components are mostly introduced by component libraries or single-package npm. And because of the wider coverage of the block, if it is used in the form of an npm package, it will allow the user to combine a large number of props to use, making the changed from the splicing of components to the splicing of props . Therefore, in terms of the block dimension, we advocate the use of source code. In the use of traditional component libraries, consumers mostly select components and then copy the demo of the display site to use, and the source code of the block will exist in the form of multiple files due to the granularity problem, so for consumers to paste the code It seems cumbersome, so we implemented the material pull tool (cli tool and vscode plug-in).

At this point, in use, the producer of the block produces the source code of the block according to the design draft/interaction draft, and the consumer of the block inserts the source code of the block into the designated position of the project through the tool, and deletes or updates the source according to their own business logic. The source code of the next block. In addition, for more fine-grained use, such as the demo pasting function that is used to UI component libraries such as antd, we also provide visual cv operations of the block tree by file.

In terms of storage, I chose to store block materials on cdn instead of npm. First of all, because of the one-time use of the source code, the block does not require strong version control (although I also support storage by version), and the consumer side does not need to perceive subsequent block upgrades. In addition, to a certain extent, the pulling of cdn is much faster than the installation of npm packages. In addition, when the cdn is uploaded every time the block is released, our dependency analysis tool will also automatically generate the dependency packages and versions required by the current block.

On the pull, after the cli tool/vscode plug-in recognizes the block name to be installed, the kernel will go to the cdn to find the @latest version of the block resource and download it to the target location specified on the consumer side (of course, it also supports the specified version number Pull), after the block is downloaded, the kernel will make a dependency diff based on the dependency of the block and the dependency of the target project, so that reminds consumers whether to install/update the material dependent on .

In the display site and local development, because our block does not use npm for storage, we precipitated local development of synchronization scripts and publishing synchronization scripts to achieve engineering automation and reduce the amount of repetitive work.

At this point, a complete block production/consumption link is roughly as shown in the figure below:

In terms of efficiency improvement, because the source code is used, the efficiency improvement scope of the block focus is more in the initialization project or the single use of a certain function on the page. will be maintained by the developer just like the normal page. , There is no such a block update 161af29ad4b06c. Then the pain points also come with it. . When the overall UI upgrade scenario occurs, the block material and the business side need to modify 161af29ad4b070 at the same time.

Page template

The template is coarser than the block granularity. The scene he focuses on is the page with fixed interaction logic. A template can be composed of multiple blocks, components, and source codes, such as common middle and backstage search list pages, reports Analyze the page and so on.

In terms of use, the use of page templates and blocks are similar, and even page templates can be counted as blocks in complex scenarios, so I won't go into details here. In addition, on the display site, we have made a special mark materials . Through this function, users can see which material resources the current template relies on, and can go to the current material details page. From another perspective, users can also see the effect of the block combination and the actual usage scenario based on the material mark of the template.

In terms of efficiency improvement, the coarse granularity of the template also limits it to be fixed only on the quick initialization of a certain page. And the drawbacks in other aspects are similar to the block.

Scenario-based solutions

Finally, there is a scenario-based solution. The scenario-based solution aims to allow developers to quickly develop front-end applications with fixed scenarios based on the source code based on page templates, engineering scaffolding, data management, release deployment and other capabilities.

E.g:
In the context of the middle and backstage management system, we can use Ant Design Pro to quickly implement a middle and backstage project.

We can also package a micro-front-end engineering template with good isolation and application divide and conquer based on the micro-front-end solution.

It can also be dumi , bisheng which focuses on static site display of productivity tools.

It can be seen that the scenario-based solution is a project-level efficiency improvement. He uses a large and comprehensive project template to help developers quickly initialize a front-end engineering project. Therefore, his reuse scope is limited to the project initialization of fixed service projects.

Concluding remarks

Finally, to summarize:

• Components: Solve single point problems

  • UI components: Solve single-point problems in common scenarios, with high reuse rate and flexibility;
  • Business components: Solve single-point problems in fixed business scenarios, with high reuse rate and flexibility, but not as good as UI components:
• Block: Solve the production of a certain block content in the page, use the source code, the reuse rate is lower than the component, and use it once;
• Page template: solve the reuse of the page level, use the source code, the reuse rate is lower than the block, and the page is initialized once;
• Scenario-based solutions: solve project-level reuse, engineering use, and the reuse rate is limited to the initialization of fixed-scene production projects;

The content of the front-end material asset latitude is shared here, and I will also deposit an article dedicated to the engineering automation under the front-end material ecology.