How to use React to develop component libraries

This time I will show you how to use React to develop component libraries, and what are the precautions for using React to develop component libraries. The following is a practical case, let's take a look.

Recently, I used react to encapsulate a set of [component libraries] for daily business needs, and roughly recorded my experiences during the entire development process. Due to space reasons, only the selection and packaging, which are more tangled during the development process, will be discussed here, and the packaging of specific components will be discussed later.

Overview

We all know that the component-based development model has greatly improved our development efficiency. By encapsulating the basic components we use daily, we can It greatly simplifies our focus on the basic UI, allows our work to focus on business logic, and separates the business and basic UI codes well, making the entire project more manageable. This is why we want to develop this component library. .

However, there are many existing React open source components, such as ant-design and material-ui, etc. Whether you need to spend effort to create a component library suitable for your own team often needs to be considered appropriately. Let’s take a look at some of the characteristics of my existing team and business:

1. There are many front-end personnel, they need to cooperate with each other, and they have enough time to develop components

2. The product business is relatively complex and requires customized development of certain components

3. There are already mature design specifications that define various basic components, basic styles, etc.

4. The current project is relatively messy, and the third-party component references are messy

It can be seen that we have the energy and foundation to encapsulate our own components, and we have The need to change the current development status through basic component encapsulation. So, this is something we should and need to get done as soon as possible.

Technical selection

For the encapsulation of component libraries, the first thing we face is technology selection and solution planning. It probably includes the following two points:

1. The most basic technical solution

2. Development process and specifications

Technical Solution Selection

Webpack + React + Sass

Since the team’s existing projects are all developed based on React+Redux, the development language we choose is undoubtedly It's React.

SASS

For css selection, although now for component development, CSS Modules and CSS-IN-JS are more popular

Modularization solution, we would prefer our components to be customizable. Therefore, for components, we use Sass as a precompiled language to improve efficiency and standardization. With css-modules, we can easily make style changes based on actual needs. For example, we have a Tab component, and we have defined its general style:

.tip-tab {
 border: 1px solid #ccc;
}
.tip-tab-item {
 border: 1px solid #ccc;
 
 &.active {
  border-color: red;
 }
}

In business, for a certain requirement, we need to fine-tune the style of the Tab component. Let the border-color be blue in the active state. Of course you can say that we can let our components expose some props, configure them for these modifications, and pass in different props corresponding to different styles. However, we often cannot meet all business needs, and it is impossible to encapsulate various styles for components. For this solution, we use css-modules to add a unique module style:

<Tab styleName="unique-tab" />

For this module, modify its basic style:

.unique-tab {
 :global {
   .tip-tab-item {
    border-color: #eee;
    
    &.active {
     border-color: blue;
    }
   }
 }
}

In this way, for this module Customized styles can be used to customize styles according to needs without polluting the global style.

Icon

For the project icon, it is planned to use the svg-sprite solution. However, because the product is in the process of continuous iteration, new icons are constantly being added. Currently, we do not package icons uniformly. Instead, we import all icons from the project during each component packaging process. Use the following method to introduce:

import Icon from '@common/lib'
import errorIcon from '@images/error.svg'
<Icon link={errorIcon} />

In fact, a better way is to package all icons uniformly and generate svg-spirte files (the specific principle can be queried svg-sprite, I will not go into details here). When we use it, we only need to quote it directly to avoid packaging every time and reduce the time webpack takes to process dependencies:

<Icon type="error" />

Development process and specifications

Regarding the development process and specifications, we follow the following principles:

1. 组件库完全独立于项目进行开发，便于后续多个项目进行使用等

2. 组件库包含三种模式：开发，测试，打包，文档案例，区分不同的入口及状态

3. 使用pure-renderautobind等尽可能保证组件的性能及效率

4. 保证props和回调的语义性，如回调统一使用handleXXX进行处理

为了便于后续的扩展，我们更希望整个组件库完全脱离于项目进行开发。保证组件库仅对于最基本的组件进行封装，将项目UI代码与业务逻辑进行分离。

针对不同的模式下，我们有不同的文件入口，针对开发模式，我们启动一个dev-server, 在里面对组件进行基本的封装，并进行调试。打包时，我们只需对组件内容进行封装，暴露统一的接口。在文档中，我们需要进行案例和说明的展示。所以我们在利用webpack的特性进行各种环境的配置：

npm run dev // 开发
npm run test // 测试
npm run build // 构建
npm run styleguide // 文档开发
npm run styleguide:build // 文档打包

组件库作为项目的最小力度支持，我们需要保证其最基本的渲染效率，因此我们采用pure-render/autobind等对其进行基本的优化。React有很多优化方式，在此不进行赘述。

打包

基础

针对组件库的打包，我们以UMD格式对其进行打包。webpack可以针对输出进行格式设置：（引自cnode)

1. “var” 以变量方式输出

2. “this” 以 this 的一个属性输出： this[“Library”] = xxx；

3. “commonjs” 以 exports 的一个属性输出：exports[“Library”] = xxx；

4. “commonjs2” 以 module.exports 形式输出：module.exports = xxx；

5. “amd” 以 AMD 格式输出；

6. “umd” 同时以 AMD、CommonJS2 和全局属性形式输出。

配置如下：

output: {
 path: config.build.assetsRoot,
 filename: utils.assetsPath('js/[name].js'),
 chunkFilename: utils.assetsPath('js/[id].js'),
 library: 'TipUi',
 libraryTarget: 'umd'
}

依赖

很明显，我们封装的是一个针对React的组件库，并不应该把React引用进去。一般我们可以采用externals的方式对其进行处理。

在这里, 我们采用dll方式将其与其他第三方依赖统一进行打包，并将manifest.json和三方依赖的输出文件输出到项目中去，在项目中也使用dllReference进行引用。避免在项目中使用到这些依赖时重复进行打包。

同时，由于我们的组件库处于一个不断维护的状态。这就需要我们维持好项目库和项目之间的打包关系，具体的流程如图所示：

在每次进行项目打包的时候，首先检测UI库是否有更新，若没有更新，则直接进行打包。反之继续检测dll的依赖是否有变化，若有，则打包dll,否则直接打包组件库内容。然后将输出结果同步到项目中，再进行最终打包。

当然，以上的这些流程都是自动进行的。

文档和示例

一个完善的文档对于一个组件库是及其重要的，每个组件有什么样的配置参数，拥有哪些事件回调，对应的Demo和展示效果。假设没有这些，除了封装组件的人，没有人知道它该如何使用。但是写文档的过程往往是痛苦的，在这里推荐几个文档生成库，可以极大的简化文档工作：

docsify 基于Vue的组件生成器，轻量好用
react-styleguidist 基于React的组件库文档生成器，自动根据注释生成文档，支持Demo展示。超好用
bisheng ant design自己写的文档生成器

我们使用的styleguidist, 可以将md自动转化为文档，支持在md内直接调用你封装好的组件并进行展示，简单好用。最后封装的文档大概长这样：

总结

In fact, there are many things worth pondering and studying in the work of encapsulating component libraries. Due to space reasons, here we only discuss the selection and packaging that are more tangled in the development process, and we will discuss the encapsulation of specific components later. . While writing, you can learn a lot by constantly referring to excellent component libraries like ant design. It is a good process to have a deeper understanding of the idea of ​​encapsulating components.

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the php Chinese website!

Recommended reading:

Singleton encapsulation addition, deletion and modification check

Detailed explanation of the scope and pre-parsing of js

The above is the detailed content of How to use React to develop component libraries. For more information, please follow other related articles on the PHP Chinese website!