幕思城>電商行情>引流>引流推廣>閑魚前端組件庫的建設(shè)

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

    2022-11-13|14:42|發(fā)布在分類 / 引流推廣| 閱讀:104

    閑魚經(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)容對當(dāng)前階段的閑魚前端來說是有極大的業(yè)務(wù)和技術(shù)價值的。

    設(shè)計

    組件庫定位

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

    需求分析

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

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

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

      實現(xiàn)分析

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

      關(guān)鍵點

      整體架構(gòu)

      • 單包

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

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

      優(yōu)點

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

      缺點

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

      • 多包

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

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

      優(yōu)點

      1. 組件發(fā)布靈活,并且天然支持按需使用
      2. 可以復(fù)用現(xiàn)在集團(tuán)的項目管理流程,實現(xiàn)bug沉淀
      3. 可以復(fù)用現(xiàn)在集團(tuá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ù)我們項目的特點:多人參與、長期維護(hù)、組件分層,最后我們選擇基于管理工具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ā),這樣他可以進(jìn)行樣式的配置。這里我們也考慮過借助社區(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 # 空格縮進(jìn)indent_size = 2 # 縮進(jìn)空格為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進(jìn)行檢查,而我們?nèi)粘i_發(fā)時很多時候使用的是ts,對應(yīng)的工具是TSLint,TypeScript 官方在 19 年放棄 TSLint標(biāo)記為廢棄,全面采用 ESLint

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

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

          • Stylelint

          安裝stylelint插件,保存就會自動fix,同時也會對有問題的樣式進(jìn)行告警

          詳見官網(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)生任何變化(例如代碼縮進(jìn),分號的移除和添加)* ● test: 新增或修改測試用例* ● refactor: 重構(gòu)代碼或其他優(yōu)化舉措* ● chore: 項目工程方面的改動,代碼邏輯并未產(chǎn)生任何變化* ● revert: 恢復(fù)之前的提交* * 提交格式:<type>(): 其中scope可忽略* * 提交實例:git commit -am 'fix(location): 登錄接口地址修改'* */
              • 組件分類

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

              組件開發(fā)

              • 腳手架

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

              • 流程

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

              s

              • demo

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

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

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

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

              總結(jié)

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

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

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

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

              難題沒解決?加我微信給你講!【僅限淘寶賣家交流運(yùn)營知識,非賣家不要加我哈】
              >

              推薦閱讀:

              安全可靠的補(bǔ)單平臺是什么?怎么補(bǔ)單才會更安全

              拼多多沒售后嗎?拼多多售后服務(wù)指標(biāo)是啥?

              拼多多能和陌生人拼嗎?團(tuán)長要錢嗎?

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

              發(fā)表評論

              別默默看了 登錄\ 注冊 一起參與討論!

                微信掃碼回復(fù)「666