做好這三個關鍵點就可以更好的實現前端業務組件庫
對于前端同學來說， 業務組件庫肯定不陌生，很多前端團隊都會選擇建設業務組件庫來解決
-
業務組件跨項目復用的問題
-
同時統一代碼實現，統一代碼質量
從而提高業務的開發效率。但是我發現埋在明確需求之后，開始調研技術方案時，很多同學并不清楚要調研哪些技術點，怎么找到某個具體方向的解決方案，找到方案之后都需要試哪些case, 以及怎么把這些方案集成在一起等等。
其實不用想那么復雜，你只需要按照以下三個技術實現的關鍵點搞定就可以了。
-
第一步："搭地基"--業務組件庫的整體架構設計
-
第二步："建主體結構"--業務組件庫的基礎技術設計
-
第三步:"粉刷外立面"-- 業務組件庫的對外文檔服務
你一定覺得這三個點還是太宏觀了，不好理解，所以接下來，我就分別介紹這三個關鍵點到底是什么。你可以參考這些關鍵點來進行相關技術調研
一. 業務組件庫的整體架構設計
對于業務組件庫的整體架構設計而言， 核心問題是業務組件庫的代碼時如何來組織和管理 。
首先，我們把代碼倉庫建好。業界一般會把同一類組件庫用單個倉庫的形式維護，并且把組件開發成NPM包的形式，這里的重點是，**你要考慮把所有的組件打包成一個大的NPM包，還是分割是一個個獨立的小NPM包 。**不要小看這個問題， 這兩種選擇會使倉庫的目錄結構有不小的差異，進一步又會影響到后面組件的開發，構建，發布，實現的技術設計
單包架構
是什么
如果你選擇把所有的組件看成一個整體，一起打包發布。這叫做 單包架構 。單個倉庫，單個包，統一維護統一管理。比如Antd
優點
它最大的優點是可以通過相對路徑實現組件與組件的引用，公共代碼之間的引用。
缺點
缺點就是組件完全耦合在了一起，必須把它作為一個整體統一發包。就算只改一個組件的一個非常小的功能，都要對整個包發布更新。
比如說 Antd，它就是作為一個整體的包來盡進行管理的。選擇使用單包架構的話，那么你就必須提供按需加載的能力，以降低使用者的成本，你可以考慮支持 ES Modules 的 Tree shaking 的功能來實現按需加載的能力。當然你也可以選擇另外一種方案，叫做"多包架構"
多包架構
是什么
每個組件彼此獨立，單獨打包發布，單個倉庫多個包，統一維護單獨管理。
- .
- ├── lerna.json
- ├── package.json
- └── packages/ # 這里將存放所有子 repo 目錄
- ├── project_1/ # 組件1的包
- │ ├── index.js
- │ ├── node_modules/
- │ └── package.json
- ├── project_2/ # 組件2的包
- │ ├── index.js
- │ ├── node_module/
- │ └── package.json
- ...
- 制代碼
優點
它最大的優勢是組件發布靈活，并且天然支持按需使用，
缺點
缺點就是組件與組件之間物理隔離。對于相互依賴，公共代碼抽象等場景，就只能通過NPM包引用的方式來實現。
--
在這些場景下的開發統一發布，相對來說沒那么方便，多包架構在業界稱之為 "Monorepo".
在前端領域，我們一般使用第三方庫 Lerna 來維護這樣的架構，Lerna針對包之間有依賴的場景做了一些特殊優化，開發模式下，它會把所有存在依賴關系的包通過軟鏈的形式連在一起，就可以很方便的本地開發聯調。所以這就要求你考慮清楚，
-
組件庫之間的組件是否有相互依賴的情況，如果有這種情況，就可以通過Lerna來進行處理
-
如果組件之間依賴特別驗證，也可選擇"單包架構"
二. 業務組件庫的基礎技術能力
當你確定了整體架構之后，就可以開始具體的功能點實現了。業務組件庫要求整體框架提供五點基礎的技術能力
1. 構建能力
這需要我們可以提供構建產物的能力，這里有很多選擇，可以選擇Webpack，Rollup Glup Grunt..... 構建組件庫推薦Rollup， 構建項目推薦Webpack. 這里需要特別注意產物的格式要求，像我們常用的cjs, esm,umd格式。
-
比如說如果你的組件考慮支持 node環境， 像需要支持SSR, 你就需要打包出 cjs格式的代碼
-
如果你的組件考慮支持
<script >標簽引用，, 你就需要打包出 umd格式的代碼
然后就需要在對應的構建工具里進行配置
除此之外，還有幾個非常容易遺漏的點，比如說
-
組件庫Bable的配置是否與項目中Babel的配置重復
-
依賴包是打包到產物中，還是使用項目中的依賴包。如:lodash, moment...
-
依賴包的樣式是否打包到產物中以及Polyfill的配置(這里以后再開一篇詳細說明吧:joy:)
2. 文檔
你需要提供一個可以實時運行的文檔服務。包括支持靜態內容的展示，以及可以查看源碼的實施運行效果，這方面有很多優秀的開源庫,比如 StoryBook&Styleguidist，Docz
這里你需要注意一個典型的錯誤行為，那就是調研的時候，只調研一些基礎的功能就開始做選擇，這樣很容易給后面挖坑，你需要考慮盡可能多的情況。比如
-
有內部狀態的代碼示例能不能支持，例如彈窗類的組件，就需要在示例中做顯示狀態的切換
-
如果考慮放移動端組件，那么展示效果能不能支持，一般來說，移動端的示例，應該是通過iframe的形式運行在一個獨立的頁面里面。比如說，fiexd定位的移動端組件是很常見的一種形式，如果不是iframe，fiexd定位的元素會鋪滿整個文檔網頁
-
文檔網站的依賴包跟組件的依賴包會不會沖突。假設兩個依賴包版本不一致的時候，需要實現一個樣式的隔離
3. 本地服務
業界一般都是用文檔服務來當本地服務的。啟動本地的文檔服務就可以查看運行的效果。這里你需要關注的是，本地服務的使用體驗好不好，比如
-
說有沒有熱更新
-
編譯速度夠不夠快
還有一個比較特別的點，有時候我們會在本地執行build構建。構建的產物跟本地生成的臨時產物要能夠做到相互隔離，互不影響
4. 質量保證
一方面我們需要提供統一的eslint功能。保證基礎的實現風格和質量
另一方面可以考慮引入單元測試的能力，業界也有很對優秀的單測框架，如Jest ，Karma
5. 數據統計
需要統計組件被多少項目使用，具體在哪個地方使用。這個能力的主要目的是提供統計數據以及了解改動的參考影響范圍。
你可以通過
-
組件內增加埋點 來進行統計。埋點方案會有一個時效性的限制，在你統計的時間周期內，如果說該組件的功能沒有用戶用到的這種情況是統計不到的
-
定時掃描分析所有代碼倉庫依賴來進行統計。可以搜索關鍵詞 dependency tree
除了上訴幾點能力以外，業務組件庫還要求整體框架提供統一換膚的能力，快速創建新標準組件的能力，批量處理組件的能力，以及預置命名等等
像發包的命令，自測的命令，自動生成ChangeLog等等這樣的命令。
三. 業務組件庫的對外文檔服務
當基礎的能力都準備好之后，我們最后再關注一下對外的一個輸出。也就是我們的文檔網站。這里我們需要把它當成一個線上服務來搭建，這里需要考慮一個具體的架構是什么
-
可能是純靜態資源
-
配到的CI怎么搭建
以上就是業務組件庫技術實現的幾個關鍵點，下面進行一個思維導圖的總結
