最近react針對日常業務需求封裝了壹套【組件庫】，大概記錄了整個開發過程中的經驗。由於篇幅原因，這裏只討論開發過程中糾結的選型和封裝，具體組件的封裝稍後再討論。
摘要
眾所周知，組件化的開發模式大大提高了我們的開發效率。封裝我們每天使用的基本組件可以大大簡化我們對基本UI的關註，使我們的工作專註於業務邏輯，並很好地分離業務和基本UI的代碼，從而使整個項目更加規範，這就是我們要開發這個組件庫的原因。
但是，現有的React開源組件有很多，如ant-design和material-ui等。是否有必要花費精力構建適合自己團隊的組件庫往往需要酌情考慮。讓我們來看看我現有團隊和業務的幾個特點:
前端人員多，需要相互配合，有余力開發組件。
產品業務相對復雜，壹些組件需要定制。
有成熟的設計規範，定義了各種基本組件和基本樣式。
目前項目比較亂，第三方組件的引用比較亂。
可以看出，我們有精力和基礎對自己的組件進行封裝，我們有通過基礎組件封裝來改變當前發展現狀的需求。因此，這件事是我們應該而且需要盡快完成的。
技術選擇
針對組件庫的封裝，我們首先面對的是技術選型和方案規劃。它大概包括以下兩點:
最基本的技術方案
開發過程和規範
技術方案選擇
Webpack + React + Sass
由於團隊現有的項目都是基於React+Redux開發的，所以我們選擇的開發語言無疑是React。
厚顏無恥
對於css選擇，盡管CSS模塊和CSS-IN-JS的模塊化解決方案在組件開發中很受歡迎，但我們更喜歡我們的組件可以定制。因此，對於組件，我們使用Sass作為預編譯語言來提高效率和標準化。有了css-modules，我們可以根據實際需要輕松地進行樣式更改。例如，我們有壹個選項卡組件，並且我們已經定義了它的常規樣式:
。提示-標簽{
邊框:1px實心# ccc
}
。提示-標簽-項目{
邊框:1px實心# ccc
& amp。活動{
邊框顏色:紅色；
}
}在業務中，我們需要針對某個需求微調選項卡組件的樣式。使其在活動狀態下呈藍色。當然，妳可以說我們可以向我們的組件公開壹些道具，針對這些更改對它們進行配置，並傳入不同的道具以對應不同的樣式。但是我們往往不能滿足所有的業務需求，也不可能為組件封裝各種樣式。鑒於這種方案，我們使用css-modules來添加獨特的模塊樣式:
& lttab style name =“unique-tab“/& gt。對於此模塊，修改其基本樣式:
。唯壹標簽{
:全局{
。提示-標簽-項目{
邊框顏色:# eee
& amp。活動{
邊框顏色:藍色；
}
}
}
}這樣，對於該模塊的定制樣式，可以很好地針對需求進行定制，同時不會汙染全局樣式。
圖標
對於項目圖標，計劃使用svg-sprite方案。但是，由於產品處於不斷叠代的過程中，新圖標也在不斷增加。目前我們沒有統壹打包圖標，而是每次打包組件時都從項目中導入所有圖標。用以下方式介紹:
從“@common/lib”導入圖標
從“@images/error.svg”導入錯誤圖標
& lticon link = { error icon }/& gt；實際上，更好的方法是將所有圖標以統壹的方式打包並生成svg-sprite文件（具體原理可以查詢SVG-sprite，這裏就不贅述了）。當我們使用它時，我們只需要直接引用它，避免了每次打包並減少了webpack處理依賴關系的時間:
& lticon type =“error“/& gt。開發過程和規範
對於開發流程和規範，我們遵循以下原則:
組件庫完全獨立於項目開發，便於後續項目使用。
組件庫包括三種模式:開發、測試、打包、文檔案例以及區分不同的入口和狀態。
使用pure-renderautobind盡可能確保組件的性能和效率。
確保props和回調的語義，例如回調由handleXXX統壹處理。
為了便於後續的擴展，我們傾向於將整個組件庫完全開發出項目。確保組件庫只封裝最基本的組件，並將項目UI代碼與業務邏輯分離。
對於不同的模式，我們有不同的文件條目。對於開發模式，我們啟動壹個開發服務器，其中組件基本上被封裝和調試。在封裝時，我們只需要封裝組件內容並公開統壹的接口。在文檔中，我們需要展示案例和解釋。因此，我們使用webpack的特性來配置各種環境:
Npm運行開發//開發
Npm運行測試//測試
Npm運行構建//構建
Npm運行風格指南//文檔開發
Npm run styleguide:build //文檔打包組件庫是項目的最低支持，我們需要保證其最基本的渲染效率，因此我們使用pure-render/autobind對其進行優化。React的優化方法有很多，這裏就不贅述了。
包
基礎
對於組件庫的打包，我們將其打包為UMD格式。Webpack可以格式化輸出:（引自cnode）
“var”作為變量輸出。
“this”作為this的屬性輸出:this【“庫”】= XXX
“commonjs”作為exports的屬性輸出:exports【“library”】= XXX；
“commonjs2”以module.exports的形式輸出:module.exports = xxx；
“amd”以AMD格式輸出；
“umd”以AMD、CommonJS2和global屬性的形式輸出。
配置如下:
輸出:{
路徑:config.build.assetsRoot，
文件名:utils . assets path（‘js/【name】）。js’），
chunk filename:utils . assets path（‘js/【id】）。js’），
庫:“TipUi”，
庫目標:“umd”
}依賴性
顯然，我們正在為React封裝壹個組件庫，我們不應該引用React。壹般來說，我們可以用外在的方式來處理它。
在這裏，我們使用dll將其與其他第三方依賴項打包在壹起，並將manifest.json和第三方依賴項的輸出文件輸出到項目中，並且還在項目中使用dllReference。在項目中使用這些依賴項時，請避免重復打包。
同時，由於我們的組件庫處於不斷維護的狀態。這要求我們在項目庫和項目之間保持良好的打包關系。具體流程如圖所示:
每次打包項目時，首先檢查UI庫是否已更新，如果沒有，則直接打包。否則，繼續檢測dll的依賴關系是否發生了變化，如果是，則打包dll，否則直接打包組件庫的內容。然後將輸出結果同步到項目中，再進行最後的打包。
當然，這些過程都是自動的。
文檔和示例
壹個完善的文檔對於壹個組件庫來說非常重要，每個組件有什麽配置參數，有什麽事件回調，對應的演示和顯示效果。假設沒有這些，除了打包組件的人之外，沒有人知道如何使用它。但是寫文檔的過程往往是痛苦的。在這裏，我推薦幾個文檔生成庫，它們可以大大簡化文檔工作:
基於Vue的Docsify組件生成器，輕量級且易於使用。
基於React的React-styleguidist組件庫文檔生成器，可根據註釋自動生成文檔，並支持演示顯示。超級好用
畢昇螞蟻設計公司自己的文檔生成器。
我們使用的Styleguidist可以自動將md轉換為文檔，並支持直接在md中調用您打包的組件並顯示它們。它簡單易用。最終打包的文檔如下所示:
摘要
其實在封裝組件庫的工作中有很多值得深思和研究的地方。由於篇幅原因，這裏只討論開發過程中糾結的選型和封裝，然後討論具體組件的封裝。在寫作時，您可以通過不斷參考ant design這個優秀的組件庫來學習很多東西。更深入地理解封裝組件的思想是壹個很好的過程。
相信看完這個案例，妳已經掌握了方法。更多精彩請關註Gxl上的其他相關文章！
推薦閱讀:
單壹包的添加、刪除、更改和檢查
js的範圍和解析前使用的詳細說明