組件（庫）開發相關總結

現狀

沒有統一組件庫，具體問題表如今如下幾點：

1. 數量：可複用組件少，常常須要造輪子，而且造完沒有抽出來以供其餘項目複用；
2. 文檔：文檔缺失，更換開發者大機率須要摸瞎看源碼，並且極可能 A 項目已經存在瞭解決方案，B 項目的開發者並不知道（或者知道了卻根本無從下手拷貝），重複造輪子；
3. 維護：1 中的輪子複用依靠複製粘貼，可維護性差，出現問題多方同步修改。

可複用組件類型

4. UI 組件：譬如彈層（Mask,SlideUp）、輕提示(Toast)以及輸入框（Input）等組件（每每還存在一些兼容性問題）；
5. 業務組件：相同業務類型可複用的組件，譬如抽獎轉盤組件；
6. 邏輯組件：譬如傳送門（Portal）、切換器（Toggler）以及校驗器（Validator）等能夠用來優化代碼結構並減小重複代碼等無形態組件。

我的思考

TO C 業務當然千奇百怪，但總有類似之處，如何與業務結合，分離可變與不可變，提升開發效率，正是工程師存在的意義（固然也須要產品【業務抽象】以及設計【ui 規範】同窗的共同參與）。

若是不一樣項目設計風格實在差別較大，也可以經過改改樣式複用，而非重寫一遍邏輯以及兼容性處理。

既要有造輪子的能力（我的），也要有不造輪子的覺悟（團隊）。

開發相關

模塊處理

一般咱們通常會提供三種形式的模塊：

• commonjs，簡稱 cjs。
• es module，簡稱 esm。便於應用打包時進行 tree-shaking。
• umd。供使用方外鏈使用，兼容 cjs 以及 amd。

想要深刻能夠看import、require、export、module.exports 混合詳解這篇文章，此處只須要知道提供何種形式的模塊以及何提供它們便可。

語法轉譯

應用開發者一般會在 babel-loader 中 exclude 掉 node_modules，因此咱們發出的包須要轉成 es5 語法，避免在低版本瀏覽器上不兼容，可使用 babel 以及 tsc 進行處理，如今 babel 也支持 typescript，建議直接使用 babel，還能夠進行相關插件配置。

在轉譯時，會存在一些輔助函數（helpers），這些函數式會在每個文件生成，建議使用@babel/plugin-transform-runtime以及@babel/runtime將輔助函數抽離，能夠減少打包體積的大小且能夠複用宿主項目的@babel/runtime。

Polyfill

1. 不許使用@babel/polyfill污染宿主環境；
2. 可使用@babel/plugin-transform-runtime結合@babel/runtime-corejs3，避免污染全局，但存在"foobar".includes("foo") 的代碼的話也是無能爲力；
3. 建議告知使用方依賴了哪些須要 polyfill 的 API，交由使用方自行配置 polyfill，不然可能會致使重複依賴或不一樣版本之間的衝突。

若是宿主應用直接一個import '@babel/polyfill'，咱們基本躺着就好。

其實關於語法轉譯還有 polyfill 有一種名爲後編譯的操做。後編譯：指的是應用依賴的 NPM 包並不須要在發佈前編譯，而是隨着應用編譯打包的時候一塊編譯。是一種性能優化手段，更多可參見webpack 應用編譯優化之路。

樣式處理

先談談單組件開發，相似react-slick這種包含樣式的典型組件。

單組件樣式處理和平時開發的應用樣式處理較爲相似，直接打包出一份 css 樣式文件，交由使用方引入便可。

固然也能夠直接將 css 打入 js 文件，使用方無需引入。

組件庫（如 antd）則較爲麻煩，由於要達到樣式按需引入的效果。

首先咱們組件庫的模塊處理方式有如下 3 種：

• cjs 與 esm：只編譯不打包（爲了按需引入）、依賴外置
• umd：既編譯也打包、部分依賴外置，部分依賴須要一同打包

若是是 umd 形式，很明顯和按需引入無緣，只須要經過rollup直接打包抽離 css 文件，交由使用方外鏈引入。

而 cjs 以及 esm 的形式，要實現樣式的按需引入，則有如下 4 種方式：

1. 使用 sass/less/stylus 等預處理器開發，相應組件內部直接 import 相應(.scss/.less/.styl)文件。

   • 優勢：1. 使用預處理器，開發體驗佳；2. 使用方無需手動引入樣式文件。
   • 缺點：1. 使用方須要關注預處理器適配問題。

2. 使用 css 開發，相應組件內部直接 import 樣式文件。

   • 優勢：1. 使用方不須要關注預處理器適配問題（css-loader 仍是要的）；2. 使用方無需單獨引入樣式文件。
   • 缺點：1. 開發體驗較差。

3. antd 處理方案。使用 sass/less/stylus 等預處理器開發，相應組件不 import 樣式文件，編寫 style/index.js 管理組件間的樣式依賴（sass/less/stylus），生成 style/css.js 管理組件間樣式依賴（css），使用方根據宿主項目預處理器選擇引入 style/index.js 或 style/css.js。

   • 優勢：1. 使用預處理器開發體驗佳；2. 使用方能夠選擇引入 css.js 樣式，不用關心預處理器適配問題。
   • 缺點：1. 使用方須要單獨引入 style/index.js 或 style/css.js（這一點可用 babel 插件解決）；2. 開發時須要編寫一份 style/index.js 用於維護組件間的樣式依賴；3. 打包時須要使用比較 tricky 的方式生成一份 style/css.js。

4. css in js 方案。使用 styled-components，相關文章：精讀《請中止 css-in-js 的行爲》。

   • 優勢：1. 開發體驗較好；2. 使用方無需單獨引入樣式文件；3. 使用方無需關注預處理器適配問題。
   • 缺點：1. 生態(postcss?沒怎麼使用過這個方案不太瞭解); 2. 緩存問題

總結

1. 不管是組件仍是組件庫，最好提供 cjs/esm/umd 等三種形式的模塊供不一樣使用情景使用；
2. 組件庫 esm/cjs 的形式須要達到按需引入， 推薦使用 gulp 結合 typescript 或 babel，只編譯不打包，單獨使用 tsc 或 babel 也能夠，但考慮到須要處理樣式，最好結合一個工具將流程串起來。umd 形式則直接使用 rollup 打包；
3. 組件庫樣式按需引入有上文四種方案，根據業務形式進行選擇，須要進行權衡取捨；
4. 單組件不存在按需引入，直接使用 rollup 打包出 esm/cjs/umd 三種形式模塊便可。

附錄：

- [dora-ui](https://github.com/worldzhao/dora-ui "dora-ui")
- [react-component-template](https://github.com/worldzhao/react-componet-template "react-component-template")
複製代碼