建站
咨詢
售后
建站咨詢
新聞中心
隨著”微前端“概念的不斷醞釀，越來(lái)越多的團(tuán)隊(duì)開始將自己的業(yè)務(wù)處理為不同的組件，編排到一個(gè)業(yè)務(wù)頁(yè)面中去，因此對(duì)組件的維護(hù)將會(huì)變得越來(lái)越重要。對(duì)于大部分前端在組件開發(fā)上都會(huì)遇到的問(wèn)題和痛點(diǎn)，本文將分享作者在組件開發(fā)上的一些思考以及應(yīng)該如何維護(hù)自己的組件庫(kù)。
十余年的湘潭網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整湘潭建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“湘潭網(wǎng)站設(shè)計(jì)”,“湘潭網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
背景
19 年 6 月左右，我發(fā)布過(guò)一篇文章《Bit 初體驗(yàn)》 。在梳理這篇文章的過(guò)程中，我可以說(shuō)深度體驗(yàn)了一把 bit 所提出的概念和做法，就像一顆種子種在我的腦海中，一開始我覺(jué)得這東西沒(méi)什么。
我還記得我第一次與我的同事分享 bit 后，他說(shuō)：
emm，雖然你講了這么多，但是我覺(jué)得好像沒(méi)有那么...有體感?
感覺(jué)沒(méi)什么卵用?
啊，emm，既然你說(shuō)了，就像你說(shuō)的。我覺(jué)得我們現(xiàn)在如果引入 bit 會(huì)不會(huì)對(duì)我們的日常工作帶來(lái)很多額外的工作量。
這種反應(yīng)很正常，我是在 18 年初，就在 Vue 的官網(wǎng)見到過(guò) bit ，當(dāng)時(shí)我點(diǎn)進(jìn)去大致瀏覽過(guò)一下。我當(dāng)時(shí)的感受就是，沒(méi)什么卵用，無(wú)非就是 " 前端垂直領(lǐng)域的 git "。對(duì)國(guó)內(nèi)的支持情況還不咋地，連一篇像樣的中文文檔都找不到。
在我們的團(tuán)隊(duì)中一下子直接切換到 bit 的工作流，這確實(shí)不現(xiàn)實(shí)，在公司有那么多的基礎(chǔ)建設(shè)都不知道 bit 這么個(gè)玩意。
但是，bit 的做法和概念，卻是非常非常有價(jià)值和可以借鑒的!
所以，我想做一件事情，一步一步的把 bit 的玩法用我們熟悉的方式引入進(jìn)來(lái)甚至有所延伸擴(kuò)展，讓大家認(rèn)同其中的好處和價(jià)值。
認(rèn)識(shí)組件
隨著近些年”微前端“概念的不斷醞釀，越來(lái)越多的團(tuán)隊(duì)開始著手將自己的業(yè)務(wù)處理為不同組件，然后通過(guò)一些微前端做法，編排到一個(gè)業(yè)務(wù)頁(yè)面中去。
那么對(duì)于組件的維護(hù)就會(huì)變得越來(lái)越重要。所以，先來(lái)看看現(xiàn)在大多數(shù)團(tuán)隊(duì)是怎么維護(hù)組件的吧!
- 大庫(kù)型，Antd、Element 標(biāo)準(zhǔn)的大庫(kù)型
- 一次型，完全業(yè)務(wù)組件，用完一次再也不維護(hù)
- 高復(fù)用型，一看就應(yīng)該單獨(dú)封裝以后給其他人用，比如：視頻播放器
- 項(xiàng)目融合型，與業(yè)務(wù)項(xiàng)目在一起，混合 store，不分你我
我暫時(shí)能想到的就這幾種類型的組件，如果你的團(tuán)隊(duì)也在維護(hù)自己的一套組件庫(kù)，那么應(yīng)該很容易理解我上面所說(shuō)的。
我相信，既然這么做了，肯定有這么做的理由和好處，沒(méi)有人會(huì)閑著沒(méi)事找麻煩做不是，那么這些做法都有什么好處和痛點(diǎn)呢?我從幾個(gè)方面入手分別分析一下。
方便、快捷
組件嘛，當(dāng)然是最快能跑起來(lái)，最方便能看到效果最好咯。就這點(diǎn)來(lái)講，還有什么比直接在業(yè)務(wù)項(xiàng)目里擼組件更快的方式嗎!?
現(xiàn)在用個(gè)展示的面板，立馬去 components 目錄擼一個(gè)。
數(shù)據(jù)?不是有 store 嗎?引入進(jìn)來(lái)不就拿到數(shù)據(jù)了!
所見即所得，現(xiàn)在改完馬上看到頁(yè)面上的效果!無(wú)法反駁..
這么看確實(shí)開發(fā)這個(gè)組件是好快了，但是從整個(gè)業(yè)務(wù)需求實(shí)現(xiàn)來(lái)看，這么做真的是最快的嗎?如果這樣的做法是最快捷的，那為什么那么多團(tuán)隊(duì)在強(qiáng)調(diào)沉淀、封裝、抽象呢?
其實(shí)很多組件當(dāng)時(shí)看起來(lái)，這輩子就只可能用一次，不用封裝?？墒峭换ジ暹^(guò)來(lái)的時(shí)候就會(huì)發(fā)現(xiàn)，這個(gè)樣式好像我在哪里見過(guò)。然后去各種業(yè)務(wù)項(xiàng)目里一頓翻，哇終于找到了，復(fù)制過(guò)來(lái)發(fā)現(xiàn)各種爆紅，定睛一看，store???
所以，聰明的團(tuán)隊(duì)早已洞察這一切，讓我們把組件都維護(hù)到同一個(gè)地方，然后大家寫好文檔，用的時(shí)候從庫(kù)里面取就可以了，有 Bug 的話統(tǒng)一修復(fù)就是，棒 !
可維護(hù)性
于是乎，大家便如火如荼的開始的組件抽象，組件整改的浩大工程。
一開始，一般會(huì)有一個(gè)團(tuán)隊(duì)中較為靠譜、能力突出的小伙子(嗯?怎么是我?)去把 Webpack、Babel、TypeScript、Sass\Less、目錄結(jié)構(gòu)、單元測(cè)試結(jié)構(gòu)、代碼規(guī)范、Review 規(guī)范、發(fā)布規(guī)范這些梳理好，然后寫一個(gè)標(biāo)準(zhǔn)的組件出來(lái)，最后再?gòu)?qiáng)調(diào)一下大家一定要按照規(guī)范認(rèn)真維護(hù)組件，書寫文檔，編寫單元測(cè)試。
從維護(hù)性上來(lái)講，大家把組件都寫在一個(gè)庫(kù)里面，然后再用到的項(xiàng)目中直接引入，業(yè)務(wù)上的問(wèn)題逐漸被分為組件問(wèn)題還是項(xiàng)目問(wèn)題，甚至有些需求可以用這個(gè)交互在組件庫(kù)中有相似的，用那個(gè)組件就可以了，來(lái)反駁產(chǎn)品和設(shè)計(jì) 。
就在大家用的不亦樂(lè)乎的時(shí)候，有一天發(fā)現(xiàn)，呀，我們的組件庫(kù)怎么打包出來(lái)有 10M 啊 !
然后找一個(gè)靠譜、能力突出的小伙子(沒(méi)錯(cuò)又是我)就去查了下，這個(gè)庫(kù)是誰(shuí)引入的?這個(gè)組件不是已經(jīng)有一個(gè)了嗎?lodash 不是這么用的呀!這個(gè)組件是干什么的，怎么沒(méi)文檔?
面對(duì)上百個(gè)業(yè)務(wù)組件，只能感嘆一聲業(yè)務(wù)迭代的可真快啊。
所以，大庫(kù)維護(hù)固然有大庫(kù)維護(hù)的好處和適用場(chǎng)景，大家能夠有這樣的抽象思維已經(jīng)是技術(shù)上的突破了，現(xiàn)在只是遇到了另外一個(gè)問(wèn)題，解它!
組件大小、加載性能
接觸 Webpack 的一些周邊工具，比如 analyzer 很容易可找出具體是什么包”霸占“了這么多的流量。
發(fā)現(xiàn)原來(lái)組件包中還有一些個(gè)組件，看上去不應(yīng)該放在大庫(kù)中進(jìn)行維護(hù)，比如那種一次性組件，二次封裝型組件。
因?yàn)檫@種組件可能會(huì)引入一個(gè)很大的第三方依賴，比如視頻播放器、Banner Swiper 等。
對(duì)于這樣的組件，最好的處理方式應(yīng)該是創(chuàng)建一個(gè)獨(dú)立的倉(cāng)庫(kù)，封裝完善后，寫好 README，發(fā)布至內(nèi)網(wǎng) NPM，供業(yè)務(wù)項(xiàng)目使用。
But you know ，這樣做成本太高，如果有時(shí)間的話，我肯定.....balabala...(一般來(lái)說(shuō)，如果你對(duì)程序員說(shuō)一個(gè)更好的方案時(shí)，除非這個(gè)方案他有參與設(shè)計(jì)，否則大部分回復(fù)都是這樣 )
當(dāng)然組件大小這方面也可以通過(guò)很多其他方式解決，比如：異步加載，NPM 引入，按需加載等等啦...那么，讓我們談?wù)勏旅媪硗庖粋€(gè)很重要、又很容易被忽略的部分吧。
組件說(shuō)明及可索引性
老板，我們今年沉淀了組件 200+，其中有幾個(gè)組件寫的特別好，同時(shí)支撐了 20+ 項(xiàng)目。
哇，這么棒!來(lái)給我看看你們寫的組件長(zhǎng)什么樣?啊，這，這樣來(lái)看看我們做的這個(gè)頁(yè)面，這個(gè)頁(yè)面里面用了這幾個(gè)組件，balabala ...
設(shè)計(jì)：聽說(shuō)你們已經(jīng)沉淀了 200+ 組件，能給我們看看有哪些組件嗎?我們?cè)谙麓卧O(shè)計(jì)的時(shí)候可以參考這些組件進(jìn)行輸出，減少溝通成本。
前端：@所有人 這個(gè)組件我們庫(kù)里面有嗎?有，CascadeSelect。哦，怎么用的?有文檔嗎?.......看下源碼吧。well...
組件的說(shuō)明及可索引性，其實(shí)僅次于組件的可用性，甚至更高。
試想下如果今天你寫了個(gè)巨牛的組件，復(fù)用性、接口設(shè)計(jì)和交互設(shè)計(jì)都非常棒，但是你有什么渠道能讓大家一下子就知道嗎，難道你要專門為此拉大家開個(gè)會(huì)?來(lái)今天占用大家1個(gè)小時(shí)的寶貴時(shí)間，介紹下我今天寫的巨牛組件。????
反過(guò)來(lái)想，如果我在寫組件的時(shí)候，反正我這個(gè)組件也沒(méi)啥亮點(diǎn)，別人應(yīng)該也不會(huì)用到，就不用補(bǔ)充文檔了吧，應(yīng)該也沒(méi)人會(huì)知道。哦豁，丸蛋
索引組件，來(lái)給大家分享一張圖：
??
??
如果有一天你團(tuán)隊(duì)的組件庫(kù)也能像這樣，一板一眼有圖有真相，那該是多么幸福和享受的一件事情!
我也知道這樣好啊!誰(shuí)不知道!如果我有時(shí)間，我肯定會(huì)....balabala...
所以你的意思是讓我們每寫一個(gè)組件不但要補(bǔ)充文檔，還要補(bǔ)充用法說(shuō)明，還要截圖!?
對(duì)，還要單獨(dú)建庫(kù)，還要考慮配置 Webpack、Babel、TypeScript、Sass\Less、目錄結(jié)構(gòu)、單元測(cè)試結(jié)構(gòu)、代碼規(guī)范、Review 規(guī)范、發(fā)布規(guī)范這些
最*實(shí)踐
說(shuō)這么多呢，主要是想帶讀者們一起思考，也是我寫作的風(fēng)格(喜歡講故事)，大部分內(nèi)容其實(shí)是前端er 都會(huì)遇到的問(wèn)題。
接下就進(jìn)入正題，說(shuō)了一大堆問(wèn)題，總得有點(diǎn)辦法來(lái)解決吧!
先看看 bit 是怎么做的吧，bit 首先自身有一定的編譯能力，內(nèi)置了 Webpack 及一些插件式 loader 來(lái)解決 React、Vue 等編譯問(wèn)題。
對(duì)于我們團(tuán)隊(duì)來(lái)說(shuō)，都是使用 React，所以咱們就先從一個(gè)編譯 React 的腳手架開始。
如果把每一個(gè)組件都作為單獨(dú)的 NPM 項(xiàng)目發(fā)布，首先要考慮的是，前端一系列的編譯環(huán)境。如果我有 N 個(gè)前端組件項(xiàng)目，每個(gè)前端組件庫(kù)的 Webpack、babel 這些都需要重復(fù)配置，那真是要頭大的事情，我只是想寫一個(gè)組件而已，為什么要考慮這些。所以我們的腳手架首先要具備一些基礎(chǔ)的編譯命令。
啊對(duì)了，腳手架還沒(méi)有名字，那就暫時(shí)叫它：comp 吧
- comp new：處理按照模板新建一個(gè)標(biāo)準(zhǔn)組件
- 初始化一個(gè)標(biāo)準(zhǔn)組件項(xiàng)目結(jié)構(gòu)，所有接入所有 comp 命令
- 初始化 Git 倉(cāng)庫(kù)
- 初始化 CI/CD 云構(gòu)建配置
- comp start：處理日常開發(fā)，附加單個(gè)組件展示及調(diào)試能力
- comp watch：處理 babel 及 scss 監(jiān)聽編譯，用于 npm link 場(chǎng)景
- comp babel：處理編譯 npm 包
- comp dev：處理監(jiān)聽編譯 umd 包，用于代理調(diào)試
- comp build：處理最后編譯過(guò)程
- webpack 編譯 UMD 包
- Babel 包
- CI\CD 過(guò)程中自動(dòng)截圖組件
- CI\CD 過(guò)程中自動(dòng)生成 README
- 其他 Hook
- comp test：處理 jest 單元測(cè)試
那么等組件初始化以后，目錄結(jié)構(gòu)就長(zhǎng)這樣：
??
??
項(xiàng)目結(jié)構(gòu)中沒(méi)有任何 webpack\babel 配置，當(dāng)然如果有特殊配置需求，可以建立 comp.config.js 進(jìn)行配置(此處借鑒很多已有的 cli 處理方式)。
這樣處理的好處是，在項(xiàng)目初始化后，用戶能見到的目錄結(jié)構(gòu)非常清晰明了，項(xiàng)目中不有很多允許配置的地方，所有組件的編譯環(huán)境基本可以保證統(tǒng)一。
這都是些非常基礎(chǔ)的功能，當(dāng)然又是不可缺少的部分，這些基礎(chǔ)命令我就不詳細(xì)介紹了，重點(diǎn)在后面。
通過(guò)這幾個(gè)問(wèn)題來(lái)介紹功能：
你平時(shí)開發(fā)組件的流程是什么樣子?
平時(shí)，一般就是根據(jù)設(shè)計(jì)稿，切分到組件后。
然后去創(chuàng)建組件，最后通過(guò)項(xiàng)目引入，一邊看著一邊開發(fā)啊。
你開發(fā)組件的時(shí)候?qū)τ谀闾峁┑?Props 是如何驗(yàn)證的?
最簡(jiǎn)單的給一個(gè) mock 看看效果唄。
或者寫一個(gè)單元測(cè)試?
那寫 Mock 的過(guò)程算不算是在寫 Usage 呢?
這個(gè)，應(yīng)該也算吧，但是這些都是散落在各個(gè)項(xiàng)目里面，有些 mock 驗(yàn)證完就刪掉了。
誰(shuí)會(huì)閑的沒(méi)事在開發(fā)的時(shí)候把這些補(bǔ)充到 README 里面去啊。
為什么他們不寫文檔?
這還用說(shuō)?因?yàn)閼袉h?
那你為啥不寫?emm，那是因?yàn)?...寫文檔這事兒吧，寫了不一定有人看，還費(fèi)時(shí)間呀!業(yè)務(wù)需求那么多!我要是有時(shí)間的話，我肯定....balabala...
OK，那我們來(lái)看下一個(gè)問(wèn)題
一個(gè)好的組件文檔需要那幾部分?
開發(fā)組件背景，注意事項(xiàng)啥的，這個(gè)沒(méi)啥太大的必要，有的組件需要的話就補(bǔ)充下，沒(méi)有的話就不用補(bǔ)充。
主要需要的一些介紹有 ：用法，Props 入?yún)ⅲ詈媚苡袀€(gè)截圖，要是有個(gè) Demo，那簡(jiǎn)直完美!
還有安裝、開發(fā)、編譯的命令介紹得有吧。
錦上添花的話最好還能有幾個(gè) badge，介紹下源碼是 TypeScript，下載量多少。
但是，要補(bǔ)充這些文檔是在太麻煩了，要一個(gè)一個(gè)整理，Props 這些信息，用的人可以在組件里面找到啊，我都有些注釋和類型定義的呀!
完成一輪心靈拷問(wèn)之后，就會(huì)發(fā)現(xiàn)在整個(gè)組件的開發(fā)過(guò)程中，開發(fā)者本人之所以對(duì)這個(gè)組件這么清楚，是因?yàn)殚_發(fā)者其實(shí)已經(jīng)為自己寫過(guò)一份 README 了。
- 用法：組件開發(fā)過(guò)程中需要看到效果，寫過(guò)一些 mock 數(shù)據(jù)，已經(jīng)知道什么樣的 props 傳進(jìn)去會(huì)產(chǎn)生什么樣的效果。
- Props 入?yún)ⅲ航M件有哪些 Props，所代表的含義是什么，每個(gè) Props 入?yún)㈩愋褪鞘裁?，已?jīng)在 TypeScript 的 Interface 及注釋中有體現(xiàn)。
- 截圖：有 mock 數(shù)據(jù)還不知道長(zhǎng)什么樣?已經(jīng)看過(guò) N 多遍了。
- Demo：根據(jù)用法和組件定義，開發(fā)調(diào)試的就是 Demo。
有了這四個(gè)最重要的介紹后，相信大部分開發(fā)者也都能知道這個(gè)組件是怎么個(gè)情況了。
所以，如果我們能把上面這些數(shù)據(jù)都收集到，是不是就可以利用腳本 自動(dòng)生成 README 文檔 了呢?
用法 / Usage
要收集用法其實(shí)很簡(jiǎn)單，如果讓組件有獨(dú)立開發(fā)的能力，不就可以保留這些 Usage 的 Mock 數(shù)據(jù)了嗎?
有些人可能沒(méi)理解我說(shuō)的”組件獨(dú)立開發(fā)的能力“是什么意思，我解釋一下下：我們平時(shí)開發(fā)一個(gè)組件，一般都是把這個(gè)組件放置于某個(gè)頁(yè)面中，一遍調(diào)試頁(yè)面一遍調(diào)試組件。獨(dú)立開發(fā)組件的意思是，直接啟動(dòng)一個(gè)頁(yè)面，可以看到組件的樣子，這個(gè)頁(yè)面展示的就是圍繞組件的所有信息。
所以在腳手架中，只要在 docs.ts 中書寫需要調(diào)試組件相關(guān)的 mock 數(shù)據(jù)，頁(yè)面就可以展示出組件的樣子，同時(shí)這些 mock 數(shù)據(jù)可以保留作為 README 文檔數(shù)據(jù)。
export default function(Component: typeof IComponent, mountNode) {
/** DOCS_START 請(qǐng)將Demo生成方法都寫在以下區(qū)塊內(nèi)，用于生成README及Riddle **/
ReactDOM.render(
navigation={true}
pagination={true}
autoplay={true}
dataSource={[
{
href: 'http://xxxxxxxx',
image: 'https://xxxxxxx.cdn.com/tfs/TB1jHkBmNv1gK0jSZFFXXb0sXXa-1440-343.png',
},
{
image: 'https://xxxxxxx.cdn.com/tfs/TB1Y_XacrY1gK0jSZTEXXXDQVXa-1416-813.png',
},
]}
/>,
mountNode,
);
/** DOCS_END **/
} 另外，如果保證這份 demo 的接口輸出統(tǒng)一規(guī)范，還可以支持直接生成在 CodePen，Riddle 這些在線編輯的代碼內(nèi)容。
試想下，你的 README 中如果出現(xiàn)一段 ：點(diǎn)擊立即體驗(yàn) ，跳轉(zhuǎn)過(guò)去后可以在線編輯實(shí)時(shí)看到效果，那對(duì)于任何看到你組件的同學(xué)來(lái)說(shuō)都是一種享受
??
??
組件參數(shù) / Props
要收集這部分?jǐn)?shù)據(jù)就比較復(fù)雜了，我們需要深入分析 TypeScript AST 語(yǔ)法樹，提取出其中組件 props 的類型以及對(duì)于Interface的注釋內(nèi)容。
經(jīng)過(guò)一番 github，終于找到可以實(shí)現(xiàn)一個(gè)可以處理這件事情的小眾庫(kù)：react-docgen-typescript(https://github.com/styleguidist/react-docgen-typescript)。
在開發(fā)過(guò)程中，因?yàn)閷?duì)一些注釋及類型輸出與我預(yù)期的不太一樣，所以我 fork 后做了一些修改，已經(jīng)可以完成對(duì)一個(gè)完整組件的 Props 做分析后輸出一份 typefile.json 。
??
??
同樣的，通過(guò)基于該能力，可以擴(kuò)展為 webpack 插件 react-docgen-typescript-loader(https://github.com/strothj/react-docgen-typescript-loader)，為組件的靜態(tài)屬性中添加 __docInfo 屬性，來(lái)聲明其屬性內(nèi)容，于是組件開發(fā)過(guò)程變可以實(shí)現(xiàn)以下效果：
??
??
截圖 / Preview
有了組件，有了 Demo，還愁沒(méi)有截圖嗎?
直接在構(gòu)建過(guò)程中用 puppeteer ，讀取運(yùn)行 docs.ts 渲染出組件，進(jìn)行截圖，然后隨著云構(gòu)建 CD 過(guò)程發(fā)到 CDN，就完事了!
最后，README 中加入一些特殊標(biāo)記，在云構(gòu)建過(guò)程中進(jìn)行 README 替換生成就可以啦!并不會(huì)影響 README 本身要叮囑的內(nèi)容。
??
??
最后，Duang !一份完整，漂亮，詳細(xì)的文檔就生成好了，整個(gè)過(guò)程我們并沒(méi)有特意寫過(guò)什么 README 方面的內(nèi)容，一切都是非常輕松標(biāo)準(zhǔn)的進(jìn)行輸出。
??
??
結(jié)語(yǔ)
在上面的一整套復(fù)雜的過(guò)程中，看上去最后好像我只得到了一個(gè)自動(dòng)生成 README 的功能。但實(shí)際上呢，其實(shí) README 只是一個(gè)順帶的產(chǎn)物。
整個(gè)過(guò)程中，我已經(jīng)拿到了這個(gè)組件的所有我想要拿到的數(shù)據(jù)，它的 Props，Usage，Preview，版本信息，包名，甚至構(gòu)建過(guò)程會(huì)同步發(fā)布該組件的 UMD CDN 包及 NPM 包。
接下來(lái)，就可以圍繞這些數(shù)據(jù)和工具，建立和擴(kuò)展很多功能和平臺(tái)。
舉幾個(gè)栗子：
- 建立一個(gè) bit 一樣的，組件平臺(tái)，把團(tuán)隊(duì)內(nèi)的組件收集起來(lái)，統(tǒng)一在平臺(tái)展示及索引
- 根據(jù)拿到 Props 類型信息做可視化的搭建平臺(tái)，把 Props 的傳參直接交給用戶設(shè)置，根據(jù)不同數(shù)據(jù)類型提供不同的 Form Setter
- 看似組件都分布在不同的庫(kù)中，卻可以通過(guò)組件 cli 做統(tǒng)一的構(gòu)建處理
- 非常輕松接入 微前端 框架，因?yàn)樗薪M件的發(fā)布構(gòu)建都是標(biāo)準(zhǔn)的構(gòu)建協(xié)議
- 通過(guò)統(tǒng)計(jì)組件發(fā)布次數(shù)，下載次數(shù)，關(guān)聯(lián) bug 數(shù)評(píng)估代碼質(zhì)量
目前在我們團(tuán)隊(duì)，已經(jīng)使用該工具產(chǎn)出 100+ 的可用組件，并且發(fā)布組件已經(jīng)成功接入到我們已有的可視化編輯器中。
看一眼結(jié)合可視化設(shè)置面板后的效果吧：
??
??
我發(fā)現(xiàn)只要實(shí)現(xiàn)過(guò)程中，沒(méi)有給開發(fā)者帶來(lái)太多的工作量，又能帶來(lái)實(shí)時(shí)可以看到的效果，開發(fā)者會(huì)很樂(lè)意為那些 Props 做一番解釋和修飾 。
我們團(tuán)隊(duì)目前產(chǎn)出的組件看起來(lái)一片通透，整齊明了。
我是一個(gè)熱愛(ài)生活的前端工程師!Yooh!????
【本文為專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
??戳這里，看該作者更多好文??
文章標(biāo)題：一個(gè)好的組件應(yīng)該是什么樣的？
文章網(wǎng)址：http://m.fisionsoft.com.cn/article/dpcdcco.html
