閑魚前端組件庫的建設(shè)

閑魚經(jīng)過這些年發(fā)展已經(jīng)變成了一個業(yè)務(wù)豐富，數(shù)量眾多且功能復(fù)雜的產(chǎn)品；而且業(yè)務(wù)高速發(fā)展，需求井噴，需要開發(fā)同學(xué)能夠快速做出響應(yīng)。同時這些產(chǎn)品線與閑魚的設(shè)計風(fēng)格有很多的共性，但各自不同的定位也導(dǎo)致了更多的差異性；制定一套各產(chǎn)品業(yè)務(wù)線通用的規(guī)范，并在各端提供一套靈活配置的組件物料庫，得到一些穩(wěn)定且高復(fù)用性的內(nèi)容對當前階段的閑魚前端來說是有極大的業(yè)務(wù)和技術(shù)價值的。

設(shè)計

組件庫定位

在確定了要做組件庫后我們對前端業(yè)務(wù)一段時間內(nèi)的設(shè)計稿進行了收集，分析發(fā)現(xiàn)各個業(yè)務(wù)線有較大差異，尤其是在營銷活動場景，為了實現(xiàn)更好的營銷效果往往需要新穎視覺和交互。在設(shè)計組件時如果為了滿足所有的場景則勢必會導(dǎo)致較大的使用成本。所以最后我們確定定位：該組件庫解決80%的產(chǎn)品線業(yè)務(wù)。

需求分析

從上面的分析可以看出UI規(guī)范是實現(xiàn)該組件庫的一個十分關(guān)鍵的基礎(chǔ)，為此我們建立了包括客戶端和設(shè)計師的虛擬小組，進行跨端的設(shè)計語言統(tǒng)一。

對于組件庫的目標整理如下

1. 提升效率：不同業(yè)務(wù)線、不同項目之間工作有大量重復(fù)的內(nèi)容，通過與設(shè)計師達成的UI規(guī)范為基礎(chǔ)建設(shè)滿足各業(yè)務(wù)線的組件，減少重復(fù)建設(shè)。
2. 提高質(zhì)量：許多重復(fù)被踩的坑，光靠文檔效率低下，沉淀組件代碼最佳實踐。
3. 統(tǒng)一的交互體驗：提供跨端的一致交互體驗。
4. 解決兼容問題：減少重復(fù)的兼容性問題和測試的兼容成本。

結(jié)合現(xiàn)有的集團能力分析得出基礎(chǔ)的能力拓撲圖一

實現(xiàn)分析

下圖是我們在建設(shè)前期分析的實現(xiàn)上述組件庫的關(guān)鍵技術(shù)點，后面我將圍繞這個思維導(dǎo)圖進行具體的分析

關(guān)鍵點

整體架構(gòu)

• 單包

把所有的組件看成一個整體，一起打包發(fā)布。

單個倉庫，單個包，統(tǒng)一維護統(tǒng)一管理，比如Antd。

優(yōu)點

1. 可以通過相對路徑實現(xiàn)組件與組件間，公共代碼間的相互引用

缺點

1. 他是完全耦合在一起的，哪怕一個組件的細小修改都需要對整個項目發(fā)一次包。
2. 由于閑魚的業(yè)務(wù)特點決定了它不僅需要考慮源碼開發(fā)的項目更需要考慮搭建場景。而如果用單包則無法復(fù)用集團現(xiàn)有的能力，導(dǎo)致搭建場景下組件重復(fù)被打包進頁面各個模塊的情況。
3. 公共代碼復(fù)用雖然有一定的收益，但是在長期維護的項目中也會大大增加維護成本

• 多包

每個組件彼此獨立，單獨打包發(fā)布，單個倉庫多個包，統(tǒng)一維護單獨管理。

例如下面的目錄結(jié)構(gòu)，所有的組件均在packages下面管理如下圖四左圖所示，每個組件的目錄結(jié)構(gòu)如圖三右圖所示。

優(yōu)點

1. 組件發(fā)布靈活，并且天然支持按需使用
2. 可以復(fù)用現(xiàn)在集團的項目管理流程，實現(xiàn)bug沉淀
3. 可以復(fù)用現(xiàn)在集團的能力，實現(xiàn)組件發(fā)版的規(guī)范控制
4. 解決搭建場景的依賴重復(fù)打包問題

缺點

1. 組件與組件之間物理隔離。對于相互依賴，公共代碼抽象等場景，就只能通過NPM包引用的方式來實現(xiàn)。
2. 組件相互依賴的調(diào)試問題。
3. 由于只能通過NPM包引用的方式來實現(xiàn)依賴，導(dǎo)致調(diào)試不變，這里我們可以用軟鏈的方式解決
4. 多依賴多版本問題
5. 例如依賴A，被組件庫的a,b組件依賴，如果使用單包不需要考慮A包的版本問題，一個項目只會有一個依賴，但是如果使用多包，a,b組件依賴同一個組件A就會存在不同版本的可能性。
6. 使用成本較高，每使用一個組件都要安裝并引入新包，業(yè)務(wù)開發(fā)同學(xué)需要一定的記憶成本。

• 結(jié)論

根據(jù)我們項目的特點：多人參與、長期維護、組件分層，最后我們選擇基于管理工具lerna的多包管理方式。

但是由于我們的組件庫在分級上有「原子組件」和「通用業(yè)務(wù)組件」之分，考慮上面的使用成本問題，我們決定將原子組件以單包的形式管理，「原子組件」和「通用業(yè)務(wù)組件」同級，則以多包的形式放在packages下管理。

UI樣式

• 樣式

1. 由于歷史原因閑魚前端的項目一直是行內(nèi)樣式，行內(nèi)樣式的設(shè)計導(dǎo)致了較多CSS使用的限制，對keyframes動畫也不支持，所以經(jīng)過調(diào)研我們確定了組件腳手架走非行內(nèi)的技術(shù)方案。
2. 使用css module的style.xxx的方案雖然能夠用添加hash后綴的方式解決重名問題，但是也導(dǎo)致修改不夠靈活，經(jīng)過綜合考慮最后決定采用添加統(tǒng)一前綴的方式，且pre作為組件的props暴露給業(yè)務(wù)開發(fā)，這樣他可以進行樣式的配置。這里我們也考慮過借助社區(qū)的babel-plugin-react-css-modules插件添加統(tǒng)一的前綴，但是實踐發(fā)現(xiàn)他需要安裝在dependence下，原因為：

When babel-plugin-react-css-modules cannot resolve CSS module at a compile time, it imports a helper function (read Runtime styleNameresolution). Therefore, you must install babel-plugin-react-css-modules as a direct dependency of the project.

考慮我們提供的是基礎(chǔ)的組件，不希望引入過多的依賴所以最后放棄了社區(qū)插件的方案。

• 樣式差異化

上面也提到不同的業(yè)務(wù)線存在主題定制、樣式差異化的需求，雖然我們在上面提供了pre最為props的方式，但是其不夠靈活且修改多個組件時成本過高，所以我們又去參考了社區(qū)主題替換的方案，基于css3 的var()能力輕易地就能實現(xiàn)想要的效果，修改樣式變量對應(yīng)的值就可以實現(xiàn)該變量對應(yīng)的樣式值的變化。

這里我們定義了全局的樣式變量，其拆分的緯度如下：

統(tǒng)一UI樣式規(guī)范

1. 色彩
2. 字體
3. 布局
4. icon

統(tǒng)一的交互動畫

1. 動畫時長
2. 動畫路徑

將拆分后的樣式變量放在:root上定義并提供global-css的cdn地址到組件腳手架中，讓組件開發(fā)同學(xué)直接使用變量。經(jīng)過一段時間實踐這里我們也發(fā)現(xiàn)該方式會引入一定的開發(fā)成本，后期會考慮通過插件的方式關(guān)聯(lián)提醒消除樣式變量的使用成本。

組件質(zhì)量

• 開發(fā)環(huán)境

前端經(jīng)過一段時間的發(fā)展對于低級bug的規(guī)避已經(jīng)有了不少工具，這里我們統(tǒng)一了開發(fā)語言TypeScript，并且添加了各個linter:

• EditorConfig

讓代碼在各種編輯器和IDE中保持風(fēng)格一致

需要注意的是有的編輯器可以直接使用，比如：WebStorm ；而有的編輯器需要安裝對應(yīng)的插件，比如大部分同學(xué)使用的編輯器Visual Studio Code。

最后使用的.editorconfig配置如下：

root = true

[*] # 匹配所有文件charset = utf-8 # 文件編碼是utf-8indent_style = space # 空格縮進indent_size = 2 # 縮進空格為2end_of_line = lf # 使用Unix-style 換行符trim_trailing_whitespace = true # 除去換行行首的任意空白字符insert_final_newline = true # 每個文件以換行結(jié)束

• ESLint

Find and fix problems in your JavaScript code

ESLint是針對js進行檢查，而我們?nèi)粘ｉ_發(fā)時很多時候使用的是ts，對應(yīng)的工具是TSLint，TypeScript 官方在 19 年放棄 TSLint標記為廢棄，全面采用 ESLint

const{ getESLintConfig } = require('@iceworks/spec');

module.exports = getESLintConfig('rax-ts');

• Stylelint

安裝stylelint插件，保存就會自動fix，同時也會對有問題的樣式進行告警

詳見官網(wǎng)：https://stylelint.io/

安裝下面的插件，會調(diào)整你的樣式順序讓代碼更有可讀性

"stylelint-config-recess-order": "^2.5.0","stylelint-order": "^5.0.0"

• Commitlint

添加了Commitlint檢查，其規(guī)范如下

/*** ● feat: 新增功能* ● fix: 修復(fù) bug* ● docs: 文檔相關(guān)的改動* ● style: 對代碼的格式化改動，代碼邏輯并未產(chǎn)生任何變化(例如代碼縮進，分號的移除和添加)* ● test: 新增或修改測試用例* ● refactor: 重構(gòu)代碼或其他優(yōu)化舉措* ● chore: 項目工程方面的改動，代碼邏輯并未產(chǎn)生任何變化* ● revert: 恢復(fù)之前的提交* * 提交格式：<type>(): 其中scope可忽略* * 提交實例：git commit -am 'fix(location): 登錄接口地址修改'* */

• 組件分類

對組件進行分類最底層是原子組件，比如button，它會被通用業(yè)務(wù)組件引用，不會經(jīng)常輕易修改；在這上面是通用業(yè)務(wù)組件，它是基于UI規(guī)范的產(chǎn)物，是隨著設(shè)計需求實時豐富的；最上面是各個行業(yè)或者業(yè)務(wù)的通用業(yè)務(wù)組件，它不基于UI規(guī)范，只是某一時期各個業(yè)務(wù)線通用的交互能力。

組件開發(fā)

• 腳手架

腳手架構(gòu)建方面主要基于集團現(xiàn)有的能力不做過多介紹。我們知道lerna 提供了不少Lerna Script供開發(fā)者使用，但是我們需要接入集團的腳手架、需要接入天馬組件的發(fā)布流程等閑魚業(yè)務(wù)定制化的需求，所以在這里我們對其在各個生命周期進行了一定修改，讓業(yè)務(wù)開發(fā)還是使用Lerna Script的指令，但是實現(xiàn)了我們需要定制化的各個需求。

• 流程

在有了上述基礎(chǔ)后我們已經(jīng)開發(fā)組件了，為了保證組件的質(zhì)量，我們制定了上面的組件開發(fā)流程。目前組件質(zhì)量腳本檢查還不夠完善，需要人工cr保障。

s

• demo

demo部分我們的技術(shù)方案是基于Storybook：

Storybook運行在主應(yīng)用程序之外，用戶可以獨立地開發(fā)UI組件，而不必擔(dān)心應(yīng)用程序特定的依賴關(guān)系和需求，使開發(fā)人員能夠獨立地創(chuàng)建組件，并在孤立的開發(fā)環(huán)境中交互地展示組件

Storybook雖然好用但同時也引入了開發(fā)同學(xué)的學(xué)習(xí)成本他們不能像以前一樣寫md，參考了shopify 的polaris項目后我們決定采用將md文件轉(zhuǎn)化為storybook的方式進行。

同時在實踐中我們也發(fā)現(xiàn)由于我們組件的整體基礎(chǔ)是Rax，而Storybook對Rax的支持是有些一言難盡的，目前我們也遇到了不少問題后面有機會可以再詳細介紹。

總結(jié)

目前組件庫的還在進一步的豐富中，開發(fā)可擴展性強、上手成本低的組件也是我們這一段時間以來遇到的一大挑戰(zhàn)。

已有的部分組件已經(jīng)在各個業(yè)務(wù)線使用，其提效的效果還是非常明顯的，減少了重復(fù)開發(fā)工作，業(yè)務(wù)開發(fā)可以無腦使用不用擔(dān)心UI還原問題，甚至還能對一些UI進行規(guī)范。

以上內(nèi)容如有不對之處，歡迎指正。

這個問題還有疑問的話，可以加幕.思.城火星老師免費咨詢，微.信號是為: msc496。

難題沒解決？加我微信給你講！【僅限淘寶賣家交流運營知識，非賣家不要加我哈】

>

推薦閱讀：

安全可靠的補單平臺是什么？怎么補單才會更安全

拼多多沒售后嗎？拼多多售后服務(wù)指標是啥？

拼多多能和陌生人拼嗎？團長要錢嗎？

更多資訊請關(guān)注幕 思 城。