Examples of component library development using React-JS Tutorial-php.cn

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. This article mainly introduces to you an example of component library development using React. The editor thinks it is quite good, so I will share it with you now and give it as a reference. Let’s follow the editor to take a look, I hope it can help everyone.

Overview

We all know that the component-based development model has greatly improved our development efficiency. Encapsulating basic components can greatly simplify our focus on the basic UI, allowing us to focus our work on business logic, and well separate the business and basic UI codes, making the entire project more manageable. This is what we want to do. The reason for the development of 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:

There are many front-end personnel, they need to cooperate with each other, and they have enough time to develop components
The product business is relatively complex and requires customized development of certain components
There are already mature design specifications that define various basic components, basic styles, etc.
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:

The most basic technical solution
Development process and specifications

Technical solution selection

Webpack + React + Sass

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

SASS

For css selection, although now for component development, CSS Modules and CSS-IN-JS are more popular modular solutions, we prefer Our components are 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;
 }
}

Copy after login

In business, for a certain requirement, we need to style the Tab component Make fine adjustments. 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" />

Copy after login

For this module, modify the basic style:

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

Copy after login

In this way, the customized style of this module can be customized to meet the 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 &#39;@common/lib&#39;
import errorIcon from &#39;@images/error.svg&#39;

<Icon link={errorIcon} />

Copy after login

In fact, a better way is to package all icons uniformly and generate svg-spirte files (for specific principles, you can query svg-sprite, I won’t 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" />

Copy after login

Development process and specifications

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

The component library is completely independent of the project to develop, which facilitates subsequent multiple Project use, etc.
The component library contains three modes: development, testing, packaging, and document cases, distinguishing different entrances and states
Use pure-renderautobind, etc. to ensure the performance and efficiency of components as much as possible
Ensure the semantics of props and callbacks. For example, callbacks are processed uniformly using handleXXX

In order to facilitate subsequent expansion, we prefer that the entire component library be developed completely separate from the project. Ensure that the component library only encapsulates the most basic components and separates the project UI code from business logic.

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

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

Copy after login

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

打包

基础

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

“var” 以变量方式输出
“this” 以 this 的一个属性输出： this[“Library”] = xxx；
“commonjs” 以 exports 的一个属性输出：exports[“Library”] = xxx；
“commonjs2” 以 module.exports 形式输出：module.exports = xxx；
“amd” 以 AMD 格式输出；
“umd” 同时以 AMD、CommonJS2 和全局属性形式输出。

配置如下：

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

Copy after login

依赖

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

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

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