The current focus is on maintaining the business component library within the group, as well as the blocks, templates, solutions that we will expand. This document mainly introduces my understanding of front-end material ecology based on my past project experience.

First of all, in my opinion, materials can be roughly divided into the following types from the granularity of reuse:

• Components;
• Block;
• Page template;
• Scenario-based solution;

component

As the smallest unit of front-end materials, components serve each business system. In terms of usage, components can either be provided to business systems in the form of component libraries/single packages, or serve as UI atoms (UI visual construction system)/logic atoms (logical orchestration system) for specific construction systems according to certain DSL specifications.

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

Here’s antD as an example: ANTD itself is provided to developers as a component library in the form of a single package and multiple components, while each underlying component of ANTD relies on a single package and single component in the React-Component.

The benefits of the single-package multi-component format are that components are more aggregated to the consumer, and common dependencies between components can be more abstractly reused, so that users can enjoy the whole package by introducing a package. The downside is that even a small change requires the entire component library to be packaged.

The advantage of the single-package single-component format is that components are naturally decoupled and components are distributed independently. The downside is that because each component is completely physically isolated, more underlying dependency packages need to be pulled out to share for common dependencies. If a single package component has chained dependencies, it is also a challenge for component developers every release, which can be addressed to some extent by the MonoRepo architecture. In addition, if a component is large, logical and has a domain-specific reuse scenario, it can also be provided in the form of a single component package, such as rich text editor, video player, etc.

Functionally, our components can be divided into view-based components that focus on views and interactions and container-based components that focus on business logic.

Container components

Container components are often used to aggregate presentation components and host certain business logic: request interfaces, merge data, and so on. Reuse of container components is often done using Render props, HOC, or more fine-grained hooks (the same goes for view components).

The view components

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

UI components

The first is UI components. In terms of function, this kind of component is mainly used as the smallest unit on the page to solve a certain kind of single point scene. In other words, this kind of component is used to find and combine the front-end page for a certain kind of scene, such as Input and Select. But the downside is that UI components that address a single point scenario require a large number of components and business logic to produce a front-end page.

UI components are generally a common paradigm that can satisfy most scenarios in the industry, and the industry often presents these UI components with common features to developers in the form of component libraries, such as AntD, ElementUI, Fusion, etc.

The 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 composition pattern for specific scenarios and business domains. For the middle and background teams with fast iteration speed and many project engineering assets, it is obviously a waste of manpower for each project and team to precipitate a set of component assets of the same business domain. Then, the combination paradigm of these components of the current business domain can be precipitated in the form of business component library.

For example, there are a large number of people, time and region selected components in the advertising area I belong to, or common form linkage in the middle and background. These components are usually INPUT, SELECT and other UI components plus certain business interaction logic and design specifications. We can then precipitate them in the form of business components and business component libraries.

In summary, UI components are intended to meet a common paradigm for most production scenarios, while business components are intended to meet a common paradigm for a particular business domain, both of which are intended to address a single point scenario on the front page.

block

Component dimensions have been able to meet most production scenarios, but for fixed mode interaction scenarios, components alone still need a lot of repeated composition work, so we use blocks to solve the problem of reuse of a piece of content.

In use, components are mostly component libraries or single-package NPM introductions. Because the block has a wider coverage, if it is used in the form of NPM package, the user will combine a large number of props, which changes the complexity from the splicing of components to the splicing of props. Therefore, on the block dimension, we prefer to use source code. On the use of traditional component library, the consumer more by selecting the component after copy to show the demo site to use, and the problem that the block due to the granularity of source will exist in the form of multiple files, so for consumers and paste the code is tedious, so we fell to the ground material pull tool (cli tools and vscode plug-in).

Up to this point, in terms of usage, the block producer produces block source code according to the design draft/interaction draft, and the block consumer inserts block source code into the project designated location through tools, and deletes or updates the pulled block source code according to their own business logic. In addition, for more granular use, such as the demo paste feature used by UI component libraries such as ANTD, we also provide visual CV operations of block trees per file.

In terms of storage, I choose to store block materials on CDN instead of NPM. First, because of the single-use nature of the source code, blocks do not require strong versioning (although I do support versioning) and consumers do not need to be aware of subsequent upgrades to blocks. In addition, CDN pull is to some extent much faster than NPM package installation. In addition, our dependency analysis tool will automatically generate the dependency packages and versions required by the current block at the same time that the block releases and uploads the CDN each time.

After the CLI tool/VScode plug-in recognizes the block name to be installed, the kernel will search the block resources of @latest version on the CDN and download the block resources to the target location specified by the consumer side (of course, it also supports pulling according to the specified version number). After downloading the block, The kernel does dependency diff based on block dependencies and target project dependencies to alert consumers whether to install/update material dependencies.

In both the presentation site and local development, since our block did not use NPM for storage, we developed synchronization scripts locally and published synchronization scripts to automate the project and reduce rework.

At this point, a complete block production/consumption link looks roughly as follows:

In terms of efficiency improvement, because of the use of source code reference, the improvement scope of block focus is more in the initialization project or a single use of a piece of function on the page, and the subsequent maintenance will be maintained by the developer like ordinary pages, there is no block update. The pain point is that the use of source code makes the iteration of the block irrelevant to the upgrade of the business. When the overall UI upgrade occurs, the block material and the business need to be modified at the same time.

The page template

Templates are coarser than blocks. They focus on pages with fixed interaction logic, and a template can be composed of multiple blocks, components, and source code, such as common background search list pages, report analysis pages, and so on.

In terms of usage, page templates and blocks are used in much the same way, and even page templates can be considered as blocks in complex scenarios, so there is no need to elaborate here. In addition, on the display site, we have made a special feature for marking materials, which allows users to see which material resources the current template depends on and go to the details page of the current material. On the other hand, the user can also see the effect of the block composition and the actual usage scenario based on the material markers of the template.

In addition, the coarse granularity of the template limits its ability to be fixed only to a quick initialization of a page. And its drawbacks are similar to blocks.

Scenario-based solutions

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

For example, in a background management system scenario, we can use Ant Design Pro to quickly land a background project.

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

It can also be an engineering tool like Dumi bisheng that focuses on the static site presentation of productivity tools.

As you can see, scenarioized solutions are project-level enhancements that use large, comprehensive project templates to help developers quickly initiate a front-end engineering project. Therefore, its reuse scope is limited to engineering initialization of fixed business items.

conclusion

To sum up:

• Component: Solve a single point of problem
  • UI components: solve single point problems in common scenarios, with high reuse rate and flexibility;
  • Service components: solve single point problems in fixed service scenarios, with high reuse rate and flexibility, but not as good as UI components:
• Block: solve the page of a block of content production, source code use, reuse rate is lower than components, a use;
• Page template: solve page level reuse, source code use, reuse rate is lower than block, a page initialization use;
• Scenario-based solution: solve project-level reuse, engineering use, reuse rate is limited to fixed scene production project initialization;

This is the end of the front end material asset latitude, and I will write an article on engineering automation under the front end material ecology.