The other day, I watched a video about a front end component library shared by Geek Time

For front-end students, business component library is certainly not unfamiliar, many front-end teams will choose to build business component library to solve

  1. The issue of business component reuse across projects
  2. At the same time unified code implementation, unified code quality

This improves the efficiency of business development. However, I found that many students did not know which technical points to investigate, how to find a solution in a specific direction, which cases to try after finding a solution, and how to integrate the solutions together when they started to investigate the technical solutions after the requirements were clear.

It doesn’t have to be that complicated, you just need to follow the key points of the following three technical implementations.

  • Step 1: “Laying the ground “– the overall architectural design of the business component library
  • Step 2: “Building the main structure “– the basic technical design of the business component library
  • Step 3 :” Paint the facade “– external documentation service for the business component library

You must think that these three points are too big to understand, so I will introduce each of the three key points. You can refer to these key points for technical research

1. Overall architecture design of business component library

For the overall architectural design of the business component library, the core problem is how to organize and manage the code of the business component library.

First, let’s set up the code repository. The industry generally maintains the same class of component libraries as a single repository and develops components as NPM packages. The key here is to consider whether you should package all components into one large NPM package or divide them into separate NPM packages. ** Don’t underestimate this, these two options can make a significant difference in the directory structure of the repository, which in turn can affect the technical design of the components that are developed, built, released, and implemented

Single packet architecture

What is the

If you choose to take all the components as a whole and package them together. This is called a single package architecture. Single warehouse, single package, unified maintenance and unified management. For example, Antd

advantages

Its biggest advantage is that relative paths can be used to reference components and common code.

disadvantages

The downside is that the components are fully coupled together and must be packaged as a whole. Even if you change a very small feature of a component, you release updates to the entire package.

Antd, for example, is managed as a whole package. If you choose to use a single package architecture, then you must provide the ability to load on demand to reduce the cost to the consumer. Consider supporting the Tree Shaking functionality of ES Modules to achieve this capability. Of course, you can choose another solution, which is called “multi-package architecture”.

More package structure

What is the

Each component is independent of each other, separately packaged and released, a single warehouse multiple packages, unified maintenance and independent management.

.├ ── project_1/ #.exercises ├── package.json ├── packages/ #.exercises ── project_1/ #1│ ├── index.js │ ├── node_modules/ │ ├─ package.json ├─ project_2/ #2Package │ ├ ─ ─ index. Js │ ├ ─ ─ node_module / │ └ ─ ─ package. The json...Copy the code

advantages

Its biggest advantage is the flexibility of component distribution and the natural support for on-demand use,

disadvantages

The downside is the physical isolation between components. For interdependencies, common code abstractions, etc., this can only be done by means of NPM package references.

—

Development in these scenarios is distributed in a unified manner, which is relatively less convenient. The multi-package architecture is known as “Monorepo” in the industry.

In the front-end field, we generally use the third-party library Lerna to maintain such an architecture. Lerna has made some special optimization for the scenarios where there are dependencies between packages. In the development mode, it will connect all packages that have dependencies together in the form of soft chain, so that local development and coordination can be very convenient. So it requires you to think about,

  • Whether the components of the component libraries are interdependent, if so, can be handled by Lerna
  • You can also select “single package architecture” if components depend on special validation

Ii. Basic technical capabilities of business component libraries

Once you have the overall architecture in place, you can start implementing specific function points. Business component libraries require the overall framework to provide five basic technical capabilities

1. Build capabilities

This requires us to be able to provide the ability to build artifacts, and there are a number of options. Choose Webpack, Rollup Glup Grunt….. Rollup is recommended for building component libraries, and Webpack is recommended for building projects. It is important to pay special attention to the formatting requirements of products, such as CJS, ESM, and UMD formats that we often use.

  • For example, if your component is considering supporting the Node environment, such as SSR, you will need to package the code in CJS format
  • If your component considers support<script > Tag reference, you need to package the code in UMD format

Then you need to configure it in the corresponding build tool

In addition, there are a few very easy to miss points, such as

  • Whether the configuration of the component library Bable is the same as the configuration of Babel in the project
  • Whether dependencies are packaged into artifacts or used in the project. Such as: lodash, moment…
  • Whether the dependency package styles are packaged into the artifact and how the Polyfill is configured (more on this later 😂)

2. Document

You need to provide a documentation service that runs in real time. This includes support for static content presentation and the ability to see how the source code is implemented. There are many excellent open source libraries for this, such as StoryBook&Styleguidist and Docz

A classic mistake to be aware of here is that when you do research, it’s easy to start making choices after just a few basic features. You need to consider as many scenarios as possible. Such as

  1. Can code examples with internal state be supported, such as popover class components, that require switching the display state in the example
  2. If you are considering putting a mobile component, then can the presentation be supported? Generally speaking, the mobile example should be run in a separate page with an iframe. For example, fiEXD location-based mobile components are a common form, and if not iframe, fiEXD location-based elements would cover the entire document page

  1. Does the documentation site’s dependencies conflict with the component’s dependencies? Suppose you need to implement a style isolation when two dependency package versions are inconsistent

3. Local services

The industry generally uses document services as local services. Start the local document service to see how it works. What you need to focus on here is whether the local service experience is good, for example

  • Say if there’s a hot update
  • Compile fast enough

Another special point is that sometimes we do build builds locally. Build artifacts and locally generated temporary artifacts should be isolated from each other

4. Quality assurance

On the one hand, we need to provide uniform ESLint functionality. Ensure the basic implementation style and quality

On the other hand, consider the ability to introduce unit testing. There are a number of good single-test frameworks in the industry, such as Jest and Karma

5. Statistics

You need to count how many projects use the component and where it is used. The main purpose of this capability is to provide statistical data and a reference to the impact of changes.

You can go through

  • Add buried points to the component for statistics. Burial schemes have a time-limit, and if the component’s functionality is not used by the user in the time period you are counting, you will not be able to count

  • The periodic scan analyzes all repository dependencies for statistics. You can search for dependency tree

In addition to several capabilities, the business component library requires that the overall framework provide the ability to uniformly skin, quickly create new standard components, process components in batches, predefine naming, and more

Such as the command to send a packet, self-test command, automatically generate ChangeLog and so on such command.

External document service of business component library

With the basic capabilities in place, let’s focus on one final output. Which is our documentation site. Here we need to build it as an online service. What is the specific architecture that needs to be considered

  1. It could be a purely static resource
  2. How to build the corresponding CI

conclusion

These are some of the key implementation points of the business component library technology, and the following is a mind mapping summary