最近針對(duì)日常業(yè)務(wù)需求使用react封裝了一套[組件庫(kù)], 大概記錄下整個(gè)開(kāi)發(fā)過(guò)程中的心得。由于篇幅原因，在這里只對(duì)開(kāi)發(fā)過(guò)程中比較糾結(jié)的選型和打包等進(jìn)行討論，后續(xù)再對(duì)具體組件的封裝進(jìn)行討論。

概述

我們都知道，組件化的開(kāi)發(fā)模式對(duì)于我們的開(kāi)發(fā)效率有著極大的提升，針對(duì)我們?nèi)粘Ｊ褂玫幕窘M件進(jìn)行封裝，可以大量的簡(jiǎn)化我們對(duì)于基本UI的關(guān)注度，讓我們的工作聚焦在業(yè)務(wù)邏輯上，很好的分離業(yè)務(wù)與基礎(chǔ)UI的代碼，使得整個(gè)項(xiàng)目更有調(diào)理，這也是我們要進(jìn)行本組件庫(kù)開(kāi)發(fā)的原因。

然而現(xiàn)有React開(kāi)源組件有很多，像ant-design和material-ui等等，是否需要花費(fèi)精力打造適合自身團(tuán)隊(duì)的組件庫(kù)往往需要酌情考慮。我們來(lái)看下我現(xiàn)有團(tuán)隊(duì)及業(yè)務(wù)的幾個(gè)特點(diǎn)：

1. 前端人員較多，需要相互協(xié)作，且有余力對(duì)組件進(jìn)行開(kāi)發(fā)
2. 產(chǎn)品業(yè)務(wù)相對(duì)復(fù)雜，需對(duì)某些組件進(jìn)行定制化開(kāi)發(fā)
3. 已經(jīng)有成熟的設(shè)計(jì)規(guī)范，針對(duì)各種基礎(chǔ)組件、基礎(chǔ)樣式等進(jìn)行定義
4. 目前的項(xiàng)目較為凌亂，第三方組件引用雜亂無(wú)章

可以看出，我們擁有封裝自己組件的精力和基礎(chǔ)，并且擁有通過(guò)基礎(chǔ)組件封裝改變目前開(kāi)發(fā)現(xiàn)狀的需求。所以，這件事情是我們應(yīng)該并且需要盡快完成的事情。

技術(shù)選型

針對(duì)組件庫(kù)的封裝，我們首先面對(duì)的是技術(shù)選型以及方案的規(guī)劃。大概包括以下兩點(diǎn)：

1. 最基本的技術(shù)方案
2. 開(kāi)發(fā)流程和規(guī)范

技術(shù)方案選擇

Webpack + React + Sass

由于團(tuán)隊(duì)現(xiàn)有的項(xiàng)目都是基于React+Redux進(jìn)行開(kāi)發(fā)的，那我們選擇的開(kāi)發(fā)語(yǔ)言無(wú)疑是React。

SASS

針對(duì)css選擇，雖然現(xiàn)在針對(duì)組件化開(kāi)發(fā)，比較流行CSS Modules和CSS-IN-JS兩中模塊化解決方案，我們更希望我們的組件是可進(jìn)行定制的。因此針對(duì)組件，我們以Sass作為預(yù)編譯語(yǔ)言，提搞效率和規(guī)范性。配合css-modules，我們可以很方便的進(jìn)行針對(duì)實(shí)際需求進(jìn)行樣式更改。例如我們有一個(gè)Tab組件，我們已經(jīng)定義好了其通用的樣式：

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

而在業(yè)務(wù)中，針對(duì)某一個(gè)需求，我們需要針對(duì)Tab組件的樣式進(jìn)行微調(diào)。讓其在激活(active)狀態(tài)下border-color是藍(lán)色的。你當(dāng)然可以說(shuō)，我們可以讓我們的組件暴露出一些props，針對(duì)這些修改進(jìn)行配置，傳入不同的props對(duì)應(yīng)不同的風(fēng)格。但是我們往往無(wú)法滿足所有的業(yè)務(wù)需求，不可能針對(duì)組件把各種樣式都封裝進(jìn)去。針對(duì)這種方案，我們采用css-modules為其添加唯一的模塊樣式：

<Tab styleName="unique-tab" />

針對(duì)該模塊，對(duì)其進(jìn)行基本樣式的修改:

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

這樣，針對(duì)該模塊的定制樣式，能很好的進(jìn)行針對(duì)需求的樣式定制，同時(shí)不對(duì)全局樣式進(jìn)行污染。

Icon

針對(duì)項(xiàng)目圖標(biāo)，計(jì)劃使用svg-sprite方案。但是由于產(chǎn)品處于在不斷迭代的過(guò)程中，新的圖標(biāo)不斷在增加。目前我們并不會(huì)對(duì)圖標(biāo)統(tǒng)一進(jìn)行打包，而是在每次進(jìn)行組件打包的過(guò)程中，從項(xiàng)目中導(dǎo)入所有的圖標(biāo)。用以下方式進(jìn)行引入：

import Icon from '@common/lib'
import errorIcon from '@images/error.svg'

<Icon link={errorIcon} />

其實(shí)更好的方式是針對(duì)所有的圖標(biāo)進(jìn)行統(tǒng)一打包，生成svg-spirte文件(具體原理可以查詢svg-sprite,在此不再贅述)。當(dāng)我們進(jìn)行使用時(shí)，只需直接引用即可，避免每次都進(jìn)行打包，減少webpack處理依賴的時(shí)間：

<Icon type="error" />

開(kāi)發(fā)流程和規(guī)范

針對(duì)開(kāi)發(fā)流程和規(guī)范，我們遵循以下幾個(gè)原則：

1. 組件庫(kù)完全獨(dú)立于項(xiàng)目進(jìn)行開(kāi)發(fā)，便于后續(xù)多個(gè)項(xiàng)目進(jìn)行使用等
2. 組件庫(kù)包含三種模式：開(kāi)發(fā)，測(cè)試，打包，文檔案例，區(qū)分不同的入口及狀態(tài)
3. 使用pure-renderautobind等盡可能保證組件的性能及效率
4. 保證props和回調(diào)的語(yǔ)義性，如回調(diào)統(tǒng)一使用handleXXX進(jìn)行處理

為了便于后續(xù)的擴(kuò)展，我們更希望整個(gè)組件庫(kù)完全脫離于項(xiàng)目進(jìn)行開(kāi)發(fā)。保證組件庫(kù)僅對(duì)于最基本的組件進(jìn)行封裝，將項(xiàng)目UI代碼與業(yè)務(wù)邏輯進(jìn)行分離。

針對(duì)不同的模式下，我們有不同的文件入口，針對(duì)開(kāi)發(fā)模式，我們啟動(dòng)一個(gè)dev-server, 在里面對(duì)組件進(jìn)行基本的封裝，并進(jìn)行調(diào)試。打包時(shí)，我們只需對(duì)組件內(nèi)容進(jìn)行封裝，暴露統(tǒng)一的接口。在文檔中，我們需要進(jìn)行案例和說(shuō)明的展示。所以我們?cè)诶脀ebpack的特性進(jìn)行各種環(huán)境的配置：

npm run dev // 開(kāi)發(fā)
npm run test // 測(cè)試
npm run build // 構(gòu)建
npm run styleguide // 文檔開(kāi)發(fā)
npm run styleguide:build // 文檔打包

組件庫(kù)作為項(xiàng)目的最小力度支持，我們需要保證其最基本的渲染效率，因此我們采用pure-render/autobind等對(duì)其進(jìn)行基本的優(yōu)化。React有很多優(yōu)化方式，在此不進(jìn)行贅述。

打包

基礎(chǔ)

針對(duì)組件庫(kù)的打包，我們以UMD格式對(duì)其進(jìn)行打包。webpack可以針對(duì)輸出進(jìn)行格式設(shè)置：（引自cnode)

1. “var” 以變量方式輸出
2. “this” 以 this 的一個(gè)屬性輸出： this[“Library”] = xxx；
3. “commonjs” 以 exports 的一個(gè)屬性輸出：exports[“Library”] = xxx；
4. “commonjs2” 以 module.exports 形式輸出：module.exports = xxx；
5. “amd” 以 AMD 格式輸出；
6. “umd” 同時(shí)以 AMD、CommonJS2 和全局屬性形式輸出。

配置如下：

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

依賴

很明顯，我們封裝的是一個(gè)針對(duì)React的組件庫(kù)，并不應(yīng)該把React引用進(jìn)去。一般我們可以采用externals的方式對(duì)其進(jìn)行處理。

在這里, 我們采用dll方式將其與其他第三方依賴統(tǒng)一進(jìn)行打包，并將manifest.json和三方依賴的輸出文件輸出到項(xiàng)目中去，在項(xiàng)目中也使用dllReference進(jìn)行引用。避免在項(xiàng)目中使用到這些依賴時(shí)重復(fù)進(jìn)行打包。

同時(shí)，由于我們的組件庫(kù)處于一個(gè)不斷維護(hù)的狀態(tài)。這就需要我們維持好項(xiàng)目庫(kù)和項(xiàng)目之間的打包關(guān)系，具體的流程如圖所示：

在每次進(jìn)行項(xiàng)目打包的時(shí)候，首先檢測(cè)UI庫(kù)是否有更新，若沒(méi)有更新，則直接進(jìn)行打包。反之繼續(xù)檢測(cè)dll的依賴是否有變化，若有，則打包dll,否則直接打包組件庫(kù)內(nèi)容。然后將輸出結(jié)果同步到項(xiàng)目中，再進(jìn)行最終打包。

當(dāng)然，以上的這些流程都是自動(dòng)進(jìn)行的。

文檔和示例

一個(gè)完善的文檔對(duì)于一個(gè)組件庫(kù)是及其重要的，每個(gè)組件有什么樣的配置參數(shù)，擁有哪些事件回調(diào)，對(duì)應(yīng)的Demo和展示效果。假設(shè)沒(méi)有這些，除了封裝組件的人，沒(méi)有人知道它該如何使用。但是寫(xiě)文檔的過(guò)程往往是痛苦的，在這里推薦幾個(gè)文檔生成庫(kù)，可以極大的簡(jiǎn)化文檔工作：

docsify 基于Vue的組件生成器，輕量好用
react-styleguidist 基于React的組件庫(kù)文檔生成器，自動(dòng)根據(jù)注釋生成文檔，支持Demo展示。超好用
bisheng ant design自己寫(xiě)的文檔生成器

我們使用的styleguidist, 可以將md自動(dòng)轉(zhuǎn)化為文檔，支持在md內(nèi)直接調(diào)用你封裝好的組件并進(jìn)行展示，簡(jiǎn)單好用。最后封裝的文檔大概長(zhǎng)這樣：

總結(jié)

其實(shí)封裝組件庫(kù)這種工作有很多的東西值得琢磨和鉆研，由于篇幅原因，在這里只對(duì)開(kāi)發(fā)過(guò)程中比較糾結(jié)的選型和打包等進(jìn)行討論，后續(xù)再對(duì)具體組件的封裝進(jìn)行討論。在書(shū)寫(xiě)的同時(shí)，不斷參考下ant design這種優(yōu)秀的組件庫(kù)，能學(xué)到很多的東西。更深刻的理解封裝組件的思想，是一個(gè)很好的過(guò)程。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論