閑魚(yú)前端組件庫(kù)的建設(shè)

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

設(shè)計(jì)

組件庫(kù)定位

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

需求分析

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

對(duì)于組件庫(kù)的目標(biāo)整理如下

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

結(jié)合現(xiàn)有的集團(tuán)能力分析得出基礎(chǔ)的能力拓?fù)鋱D一

實(shí)現(xiàn)分析

下圖是我們?cè)诮ㄔO(shè)前期分析的實(shí)現(xiàn)上述組件庫(kù)的關(guān)鍵技術(shù)點(diǎn)，后面我將圍繞這個(gè)思維導(dǎo)圖進(jìn)行具體的分析

關(guān)鍵點(diǎn)

整體架構(gòu)

• 單包

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

單個(gè)倉(cāng)庫(kù)，單個(gè)包，統(tǒng)一維護(hù)統(tǒng)一管理，比如Antd。

優(yōu)點(diǎn)

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

缺點(diǎn)

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

• 多包

每個(gè)組件彼此獨(dú)立，單獨(dú)打包發(fā)布，單個(gè)倉(cāng)庫(kù)多個(gè)包，統(tǒng)一維護(hù)單獨(dú)管理。

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

優(yōu)點(diǎn)

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

缺點(diǎn)

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

• 結(jié)論

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

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

UI樣式

• 樣式

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

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ǔ)的組件，不希望引入過(guò)多的依賴所以最后放棄了社區(qū)插件的方案。

• 樣式差異化

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

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

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

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

統(tǒng)一的交互動(dòng)畫(huà)

1. 動(dòng)畫(huà)時(shí)長(zhǎng)
2. 動(dòng)畫(huà)路徑

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

組件質(zhì)量

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

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

• EditorConfig

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

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

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

root = true

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

• ESLint

Find and fix problems in your JavaScript code

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

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

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

• Stylelint

安裝stylelint插件，保存就會(huì)自動(dòng)fix，同時(shí)也會(huì)對(duì)有問(wèn)題的樣式進(jìn)行告警

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

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

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

• Commitlint

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

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

• 組件分類(lèi)

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

組件開(kāi)發(fā)

• 腳手架

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

• 流程

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

s

• demo

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

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

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

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

總結(jié)

目前組件庫(kù)的還在進(jìn)一步的豐富中，開(kāi)發(fā)可擴(kuò)展性強(qiáng)、上手成本低的組件也是我們這一段時(shí)間以來(lái)遇到的一大挑戰(zhàn)。

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

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

這個(gè)問(wèn)題還有疑問(wèn)的話，可以加幕.思.城火星老師免費(fèi)咨詢，微.信號(hào)是為: msc496。

難題沒(méi)解決？加我微信給你講！【僅限淘寶賣(mài)家交流運(yùn)營(yíng)知識(shí)，非賣(mài)家不要加我哈】

>

推薦閱讀：

安全可靠的補(bǔ)單平臺(tái)是什么？怎么補(bǔ)單才會(huì)更安全

拼多多沒(méi)售后嗎？拼多多售后服務(wù)指標(biāo)是啥？

拼多多能和陌生人拼嗎？團(tuán)長(zhǎng)要錢(qián)嗎？

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