組件庫劃分

要想設計一個靈活好用的組件庫，第一步就是要合理的劃分組件，組件的粒度足夠細，邊界足夠清晰，這樣才能最大程度地復用組件。

 

從一張圖介紹各種組件的區(qū)別，基礎組件，也就是與業(yè)務功能無關的組件，比如 antd/fusion 中提供的組件，upload， dialog 等等這些。但是只有這些基礎組件是遠遠不夠的。

比如，你可能會經常遇到這樣的場景：

• 前端開發(fā): 設計師又造“新輪子”了， 為什么就不能本本份份使用 fusion 或者 antd 的基礎樣式呢？
• 設計師: “我覺得這個基礎樣式沒有靈魂，我覺得這樣比較好看”

這種時候，業(yè)務組件就有用處了。此時可以利用 fusion 或者 antd 的基礎組件，進行二次封裝，形成自己產品的獨特組件，也稱“業(yè)務獨特領域的組件”。

但事實上，還是有很多場景，他可能會頻繁變更，如果開發(fā)一個組件，里面的傳參等等都可能會不停變更，此時就可以直接用“區(qū)塊”來實現。直接提供一個組件代碼模版，讓使用方直接復制粘貼，然后在里面修改他的內容。

再往高一點，頁面級別，也稱為模版， 比如“登錄頁”，可能不同產品之間，這個登錄頁中間一部分邏輯是變化不可控的，那可以直接提供一個頁面模版，供使用方直接使用， 比如 頁面模版^[1]。

好了， 通過上面的講述，我們知道在什么場景下該使用什么組件，知道如何劃分組件可以讓我們的組件庫更加靈活強大，接下來就要講一下如何開發(fā)一個組件了。

組件開發(fā)

• 設計師: 哎，我這里的間距要從 14px 改成 16px， 然后字體顏色改成 ***
• 前端開發(fā): 我…………

難道一個前端每天都要在這調整樣式嗎？那未免太無趣了…… 此時一個主題變量就很重要了。

1. 主題變量

我們可以提前跟設計師約定， 比如主字體大小多少，主顏色是什么，然后設計師出稿時按照設置的變量來出。

這樣前端跟設計師之間就通過一個 scss 變量來銜接，搭建一個主題配置的網站，如下【fusion 主題配置】，在開發(fā)業(yè)務組件的時候，注入該網站配置的相關變量。

設計師可以在這里設置他想要的變量，最后生成對應的 scss 變量，如下截圖：

 

經過下面的操作流程，在實際項目中，前端開發(fā)只需要重新編譯構建項目即可修改組件樣式， 真正從樣式中解放出來～

好了，除了 css 樣式，做一個組件還需要注意以下一些事情。

2. 如何讓一個 npm 包體積最小

1. umd -> esm

2. 配置 peerDependencies 。。。

 "peerDependencies": {    "react": ">=16.12.0",    "react-dom": ">=16.12.0"  }

如上的配置，可以讓組件庫下的 node_modules 不安裝 react，同時指定組件庫使用方需安裝的 react/reactDOM 的版本。

 

3. 配置對應的 externals

3. 文檔生成

之前分享過一篇 react 文檔自動生成的文章， 感興趣可以看一下

4. commit 規(guī)范 & changelog 生成

首先，使用 husky 插件， 在 pre-commit 階段添加鉤子，限制該項目提交的 git commit 信息。

之后，我們再利用 conventional-changelog^[2] 插件， 把歷史 commit 信息進行篩選提煉，自動化生成統(tǒng)一規(guī)劃的 CHANGELOG 文件。

5. 打通設計師&前端工具

如果前端埋頭造輪子，相信我，你們的設計師依然不會放過你們，因為他不知道你們造了什么輪子

所以此時實現一個 sketch 插件，將實現的組件同步到 sketch 插件中，這樣每次設計師就可以看著已有的組件來拖拽生成設計稿。大大減少前端&設計師的溝通。如下圖：

 

 

實現上面一個完整的鏈路，可以大大提升前端的開發(fā)效率。不過一個公司如果想 從 0 搭建這樣一套完整的組件庫，務必要投入大量的人力。這時候，可以上 fusion 上看看， 上面什么都有。