Under the React ecosystem, a mature front-end team is always faced with a problem: how to improve the team’s development efficiency?

A system has a large number of business scenarios and business codes, and similar pages and codes emerge endlessly. How to manage and abstract these similar codes and modules is certainly a problem that many teams will encounter. Constantly copying code? Or is it abstracted as a UI component or business component? Obviously the latter is more efficient.

Now we have a choice: first, we can choose the existing component libraries in the React ecosystem, such as antDesign, Material-UI and other mature component libraries. The second is for the team to develop its own component library. Zent provides a set of basic UI components and common business components. At present, we have 45+ components, and these components have been widely used in all kinds of PC business of Zent. In this article, we’ll take a look at how to develop a good React library and what makes a complete library work.

One, choose open source? Or build your own wheels?

React environment has a lot of excellent UI component libraries, domestic well-known antDesign, foreign Material-UI, are relatively stable and excellent component libraries. So why should we develop a component library ourselves? The reasons are as follows:

  • There are independent design specifications for each line of business PC product, including but not limited to component style and interaction mode.
  • The business scenarios of PC products such as Youzan Micro mall, retail and beauty industry are complex, requiring in-depth customization of some common components, such asDesign 和 SKUComponents.
  • Need to support PC products of multiple business departments at the same time.
  • Team members participate in the development of the component library in an open source mode, during which there will be a lot of discussions and collisions, which is also a training process for the team.

Two, component library composition

Building a complete component library requires consideration of:

  • Component Design Idea
  • Component code specification
  • Component development process
  • Component test
  • Component maintenance (including PR/issue management, package distribution and documents)

1. Component design idea

Component is for some of the same business scenario and interactive mode code abstraction, component library should first ensure that the components of the visual style and consistent interaction specification, X component in A business scenario is an interactive, in the business scenario B is another UI style, so can’t to abstraction of X, greatly increase the building cost components. Therefore, the first step in designing components is to abstract and agree on a uniform set of visual styles and interaction specifications.

Second, the props definition of the component library needs to be extensible and fully controlled inside the component to keep it consistent with inputs and outputs. Let’s look at an example of Button.

// Button is a react component of Zent
<Button
  type="primary"
  className="customer-classname"
  loading={true}
  disabled={false}
  size="large"
  onClick={this.handleClick}
>
  {children}
</Button>
Copy the code

This isa Button component. We define props for marking state. For example, type represents the visual style of the Button, size represents the size, disabled disables, loading state, and so on. All the states are determined by the props passed in, so we can customize the className for the styling and children for the display of the Button.

Button even provides functionality for an A tag by passing props: href on the Button.

// Button as <a> <Button type="primary" className="customer-classname" href="https://www.youzan.com" target="_blank" > </Button>Copy the code

We need to make a few conventions:

  • All state of the component is controlled by props
  • The children component supports custom Dom structures
  • Do not write out the Dom structure inside the component

2. Component code specification

Nice front-end internal component library, using the open source Lint tool — Felint.

Felint is a front-end code checker that integrates ESLint, Stylelint, and Git Hook. Felint does the following three things for your project:

  1. Initialize the ESLint /stylelint configuration file. React, VUE, ES5, and ES6 projects provide specific configuration schemes
  2. Install esLint /stylelint and its dependencies into the node_modules of the current project
  3. Mount git hooks to enforce validation when you submit code

Please refer to the official doc — felint document address for details.

3. Component development process

After agreeing on the design ideas and code specifications of components, we can then participate in the development of components. The basic development process of component library includes the following points:

  • Component initialization
  • Component Coding
  • Components in the Demo

Zent has a component initialization command: yarn new-component. This command does most of the component initialization, including automatically creating the directory and template code required by the component, and adding component JS and CSS code. From there, we can start writing component code, with the code style and specification strictly following lint’s specifications, and no code can be submitted if it doesn’t. After writing the component, you need to write the component Demo and run it by starting the server locally, which can be used as a component debugging tool.

4. Component testing

Jest, Mocha, Karma, etc. Zent component library uses jest + enzyme.

// Button UI test
import { mount } from 'enzyme';

describe('Button', () => {
  it('Button UI test', () = > {const wrapper = mount(<Button>OK</Button>);
    expect(wrapper.hasClass('zent-btn')).toBe(true);
    expect(wrapper.text()).to.equal('OK');
  });
});
Copy the code

The limitations of using Jest for UI testing are that you can only test basic DOM structures and styles, some logical interactions can’t be measured, and only cover most cases. Yarn test is used to execute the test script. The test result is displayed on the terminal.

5. Maintain components

Routine maintenance of components accounts for a large part of the life cycle of the whole component library. After the component library is built, component functions will be continuously iterated in the follow-up, maybe bug fix or new feature. We manage the iteration of these components through PR and issue. We need to manage the changelog component well. In general, component maintenance mainly includes PR/issue handling, package sending, and Changelog management.

The following uses Zent as an example to introduce the PR specification.

PR title rule: [Bug fix/Breaking change/New Feature] Component name: Modified content description

  • The square brackets are used to distinguish PR/issue types: bug fix – Component bug fixes; Breaking change – incompatible changes; New feature – New feature
  • Make the changes as brief as possible, summarizing the PR changes or describing the issue
  • Please use Chinese for description
  • The component name must be in English with a capital letter

PR is used to generate Changelog. Standard PR helps to generate a relatively clear Changelog at a glance. Take a look at Zent’s example:

Component contract

Only those who have the permission to send packets can send packets. Zent sends packets by component library. Yarn Build packages the Zent code and runs the yarn publish command to send packets.

Component document

A good DOC is the standard of a good component library. Good documentation can improve the overall quality and goodwill of the component library. If the team is willing to take the time to write a DOC, their component library should not be too bad. Sometimes you even need to be bilingual in Chinese and English.

Attached here is the DOC address of the Zent component library: Zent.

Third, summary

In this paper, we explain how to build a React component library from the aspects of component design, coding specification, development process, testing, and daily maintenance. We also take Zent as an example to describe how to do it. Any component library needs to go through this life cycle, but we need to consider the following: How to create a good component library ecological environment? We need to think of some way to get more people involved in common as defenders of the component library, open source is in order to make the output to the React of ecological environment, on the front end componentization has become a fait accompli of today, we don’t need to repeat the wheel, but need to try a new breakthrough in the field of componentization, from the bondage of the front-end technology, Stand at the engineer’s level and abstract your own code. We have a lot more to do on the componentization road, and Zent is just the beginning.