頭條小游戲入口 ttc帶你看動(dòng)漫？很多人不了解，今天各百科為大家?guī)硐嚓P(guān)內(nèi)容，下面小編為大家整理介紹。
我們今天要講的話題是構(gòu)件庫從零到一的設(shè)計(jì)與實(shí)踐。大家看這個(gè)題目應(yīng)該就很清楚了。作為前端工程師，平時(shí)的開發(fā)離不開組件庫。你對(duì)Ant Design、Element等組件庫非常熟悉，但是如何自己設(shè)計(jì)一個(gè)組件庫或者最好的做法是什么？今天我打算借此機(jī)會(huì)和大家分享一下百度外賣的經(jīng)驗(yàn)。
這是基于Vue的github的組件庫，我們自己實(shí)現(xiàn)的。這是地址，有興趣可以看看。雖然在github上維護(hù)，但基本都是內(nèi)部使用，所以對(duì)外沒有做太多宣傳。
回到今天的話題，如何從零到一建立自己的組件庫。這是我們今天的具體內(nèi)容，首先是認(rèn)知和目標(biāo)，構(gòu)件庫的規(guī)劃，具體的架構(gòu)設(shè)計(jì)和實(shí)踐，最后是構(gòu)件化的設(shè)計(jì)思路。
這部分具體包括什么是組件庫，是什么概念，我們?yōu)槭裁匆鲞@個(gè)組件庫，具體的好處是什么，因?yàn)槲覀兌际窃诠荆覀冏龅南嚓P(guān)的事情也會(huì)為公司產(chǎn)生一定的收益。能不能具體做，或者需要做什么，怎么做，什么時(shí)候什么時(shí)候完成？
可能有的同學(xué)會(huì)說，我可以直接開始寫代碼，但是需要強(qiáng)調(diào)的是，組件庫不僅是技術(shù)，還有方法論，這很重要。這個(gè)方法論后面會(huì)跟你詳細(xì)解釋。
現(xiàn)在我們做這些組件肯定是要反哺業(yè)務(wù)的，如果業(yè)界或者是相關(guān)的社區(qū)已經(jīng)有很優(yōu)秀的輪子了，你又重復(fù)造輪子或者是你做出來的東西還是跟別人有一定的差距的話，你的投入就會(huì)顯得沒有具體的產(chǎn)出，另外是團(tuán)隊(duì)的構(gòu)成，比如說同學(xué)他是否掌握具體的相關(guān)的技術(shù)，或者是團(tuán)隊(duì)同學(xué)對(duì)于一些技術(shù)棧的偏好之類的，這些事情也是對(duì)我們具體做這個(gè)事情也是有影響的。
我們具體的目標(biāo)，當(dāng)時(shí)我們做具體的這個(gè)組件庫的時(shí)候，目標(biāo)一定要明確，內(nèi)容是一個(gè)基礎(chǔ)的組件庫，就是他是沒有任何業(yè)務(wù)相關(guān)的邏輯，因?yàn)槲覀冏鼋M件庫是強(qiáng)調(diào)復(fù)用，業(yè)務(wù)的邏輯是經(jīng)常變化的，但是基礎(chǔ)組件的交互是比較固定的，另外是組件的數(shù)量，整個(gè)庫的容量是多少，具體的形態(tài)是什么樣的，分發(fā)，以那種方式提供給用戶，用戶是可以使用一些其它的拷貝或者是線上資源方式，另外是維護(hù)人力流程這塊。
接下來我們就開始說一下具體的在做這件事情之前具體怎么樣對(duì)組件庫做一個(gè)規(guī)劃。
我們說規(guī)劃的核心是什么，實(shí)際上是兩個(gè)字是取舍，取舍是做什么事情不做什么事情，具體是怎么樣分工，具體的時(shí)間怎么安排。
我們這個(gè)組件庫是做技術(shù)組件庫，不做業(yè)務(wù)組件庫，我們做高頻的組件，一定是在我們的業(yè)務(wù)里面做比較高頻的組件我們才會(huì)考慮開發(fā)，可能是業(yè)務(wù)里用的比較小眾的情況下就不會(huì)選擇開發(fā)，還有一點(diǎn)沒有框架的依賴，比如說jquery等 。。為什么沒有框架依賴，相關(guān)的框架會(huì)增加我們體系的大小，另外組件庫本身不應(yīng)該有具體的傾向性的，因?yàn)樗敲嫦蜷_發(fā)者的，如果組件庫有相關(guān)的傾向性很可能會(huì)對(duì)開發(fā)者造成一定的困擾。
說一下分工這塊，我們組件庫是一個(gè)團(tuán)隊(duì)合作的項(xiàng)目，這個(gè)組件庫是聚焦在幾個(gè)人身上做還是大家每個(gè)人有一個(gè)這樣的情況，首先我們是覺得是需要結(jié)合一些業(yè)務(wù)項(xiàng)目的情況，我們不能專職做這個(gè)東西，平時(shí)有業(yè)務(wù)的開發(fā)，我們要保證投入，通過一些相關(guān)的設(shè)計(jì)方式我們正式質(zhì)量的差異，另外我們要落實(shí)具體的規(guī)范。
那接下來是落實(shí)具體的規(guī)范就給和大家分享一下我們相關(guān)的組件庫的規(guī)范。這個(gè)事情是對(duì)組件庫來說顯得尤其的重要，因?yàn)榻M件庫有可能是一個(gè)團(tuán)隊(duì)協(xié)作的產(chǎn)物，或者組件庫本身是一個(gè)整體，必須要有相關(guān)的規(guī)范。
我們認(rèn)為組件庫這塊的規(guī)范有很多，總結(jié)了一下，比如說評(píng)審的規(guī)范，這個(gè)組件庫應(yīng)該是什么樣的，API怎么設(shè)計(jì)，或者是屬性相關(guān)的東西應(yīng)該怎么設(shè)計(jì)，評(píng)審的規(guī)范，另外是代碼的規(guī)范，代碼應(yīng)該有什么，遵循一個(gè)什么樣的代碼規(guī)范，另外是開發(fā)的規(guī)范，大家開發(fā)的模式是一樣的，最后把這個(gè)規(guī)范，因?yàn)榻M件庫本身是生態(tài)最后肯定離不開做維護(hù)，相應(yīng)的維護(hù)也是系統(tǒng)規(guī)范的。
首先這個(gè)是一個(gè)基本的規(guī)范，大家可以看上一頁的圖，代碼的規(guī)范和開發(fā)的規(guī)范，這一部分是在組件庫本身的維度上面我們可以對(duì)他做一些約束，首先是在我們的開發(fā)規(guī)范里面具體的，我們是用ES6去做，ESLINT使用我們百度的具體的代碼的規(guī)范，相關(guān)的東西大家可以去到我們百度FEX的github庫中搜到，做一些規(guī)范檢查，我們最后的CSS的語言是使用的LESS，說到規(guī)范，大家可能有一些同學(xué)知道會(huì)有一些，比如說是OOCSS，BEM這些規(guī)范，這種規(guī)范現(xiàn)在在社區(qū)內(nèi)的意見并不是非常統(tǒng)一，現(xiàn)在的框架，比如說Vue可以通過scope把組件Css與外部給隔離掉，或者是CSS IN JS這種相關(guān)的技術(shù)給他可以做到，去隔離這種CSS的污染，像BEM的規(guī)范，實(shí)際上是會(huì)增加一些相關(guān)開發(fā)的負(fù)擔(dān)，因?yàn)樗歉M件本身是一個(gè)平行的狀態(tài)。
在命名的規(guī)范這塊是可能對(duì)于我們組件庫來說，有具體的組件名，具體的API相關(guān)的都會(huì)涉及到命名，實(shí)際上這也是一個(gè)比較難的一個(gè)事情，因?yàn)槭紫饶阈枰喢鞫笠€要統(tǒng)一，相對(duì)來說就是每個(gè)平行的組件，類似的名稱是要統(tǒng)一的，肯定要語義化，方便開發(fā)者去理解，還要貼近我們?cè)南嚓P(guān)的命名。
貼一些例子，就是大家可能是可以看到這上面的一些，比如說我們列舉的一些好的例子與不好的例子，大家可以看一下。
對(duì)組件庫來說他是基于一個(gè)框架相關(guān)的，比如說像Ant Design他是屬于一個(gè)React相關(guān)的組件庫，Element是基于Vue開發(fā)的，首先這些框架本身的思想是不盡相同的，相關(guān)的開發(fā)范式也是不盡相同的，這些也是針對(duì)框架做不同的規(guī)范。
舉個(gè)例子，比如說在Vue對(duì)你定義的一些數(shù)據(jù)做一些簡單的處理，表達(dá)式說清楚就不必要計(jì)算屬性/method這種具體在代碼里寫的東西，這個(gè)也是我們推薦的方式。
最后是開發(fā)規(guī)范，當(dāng)然有一些同學(xué)喜歡用html/css/js三個(gè)文件這種方法，我們統(tǒng)一定的文件的方式，首先他是可以和webpack很好的去做一個(gè)相應(yīng)的解析，我們這種底層的具體的做打包或者是做相關(guān)開發(fā)的東西都是用webpack.另外樣式分離我們不會(huì)在Vue去寫，我們單獨(dú)的把樣式抽離出來，能夠更統(tǒng)一的使用相關(guān)的一些LESS變量，會(huì)比較方便，我們還要統(tǒng)一一些工具庫，DOM操作，通信相關(guān)的一些庫，我們會(huì)統(tǒng)一具體的動(dòng)畫庫，動(dòng)畫庫在Vue里面就是trasition.還要統(tǒng)一開發(fā)環(huán)境和展示站，最后維護(hù)就是我們提交的是使用github這種相關(guān)的工作流，。
上面可能是說了很多類似是規(guī)劃和規(guī)范相關(guān)的東西，我們之前說的方法論相關(guān)的一些。下面是著重給大家介紹一下具體的架構(gòu)設(shè)計(jì)和工程化這塊的內(nèi)容。
大家可能是可以打開看一下這個(gè)圖，這個(gè)是我們的一個(gè)具體的結(jié)構(gòu)的設(shè)計(jì)，大家看下面的紫色的這部分是我們具體的組件的一個(gè)容器，包括我們的Assets,比如說圖片字體這些的靜態(tài)資源，DEMO這個(gè)是專門寫組件的文檔的，對(duì)于每一個(gè)組件是一個(gè)單文件的Vue，我們CSS剛才說了已經(jīng)是分離出去了，相關(guān)的一些工具庫和一些相關(guān)的Mixin，左邊這塊是一個(gè)單頁，我們的組件肯定是需要有一個(gè)展示站的單頁，這塊我們的開發(fā)環(huán)境和我們的文檔是統(tǒng)一的，肯定是離不開為這個(gè)組件庫寫文檔。
在說一下我們的CSS架構(gòu)相關(guān)的，首先之前我們提到過我們是用這種語言寫的，預(yù)處理，首先是需要一個(gè)環(huán)境適應(yīng)性，當(dāng)前只在組件的內(nèi)部去產(chǎn)生生效，不會(huì)被其它的東西污染，還要具體的相關(guān)的交互是要統(tǒng)一的。我們的主題是可以更換的。另外是一些其它的高度的自定義，這塊是提到一個(gè)Bootstrap, 這個(gè)東西大家很熟悉，就是可能是很多同學(xué)并沒有深入利用好他的實(shí)踐，就是這個(gè)庫的話內(nèi)部的實(shí)現(xiàn)是比較精妙的，具體的我是建議大家可以看看這個(gè)原碼，我們這塊的實(shí)現(xiàn)也是去參考了Bootsrap，有一些同學(xué)會(huì)問為什么你們不直接基于Bootstrap來做，我們最開始的時(shí)候我們的確是基于這個(gè)做的，但是后面實(shí)際上會(huì)發(fā)現(xiàn)一些問題，比如說如果說你本身的站點(diǎn)原來大量使用Bootstrap的話, 可能是會(huì)對(duì)這個(gè)做一些自己的定義，比如說是btn-info這樣的類名可能會(huì)被做一些自定義，如果我們?cè)谶@里面直接使用這個(gè)類名肯定是會(huì)被污染的。對(duì)于關(guān)于具體的我們這個(gè)長什么樣，很大程度上是由我們CSS決定的，如果你一開始做一個(gè)組件庫的話，如果說你是一個(gè)前端或者是你是一個(gè)設(shè)計(jì)都很擅長的同學(xué)，你可以自己搞一套，但是對(duì)于很多前端工程師不是非常懂設(shè)計(jì)語言或者是其它的情況下最好是參照一些業(yè)界已有的語言，比如說像Material Design, Ant Design這樣的設(shè)計(jì)語言。
大家可以打開這個(gè)圖看一下，這個(gè)是一個(gè)CSS具體的結(jié)構(gòu)，首先是左邊是基礎(chǔ)相關(guān)的東西，可能是一些CSS的，比如說Noramlize, Reset做一些基礎(chǔ)的工作，我們定義相關(guān)的顏色相關(guān)的字體，圖標(biāo)，grid柵格相關(guān)的東西。
在顏色的話對(duì)于組件庫來說肯定是會(huì)定義一個(gè)主色，另外一個(gè)是info是體現(xiàn)一個(gè)信息傳遞，success體現(xiàn)一個(gè)信息的成功或者是一個(gè)操作的成功，warning體現(xiàn)一個(gè)警告，error體現(xiàn)一個(gè)錯(cuò)誤的操作，類似的這些基本色一定要定義好。在我們從黑到白定義的一些比如說是灰度方面的顏色，less相關(guān)的函數(shù)是可以實(shí)現(xiàn)的。
圖標(biāo)這塊是先想說一個(gè)問題，LICENCE是很重要的，看他是不是MIT的，如果是一些付費(fèi)或者是商業(yè)使用某些圖標(biāo)是不讓你用的，雖然我們做的是內(nèi)部的組件庫，我們?cè)趃ithub上做這個(gè)事情，所以我們是使用開源的圖標(biāo)庫，第二個(gè)是字體的資源的打包或者是分散，比如說字體大家應(yīng)該很熟悉，現(xiàn)在的icon字體會(huì)有一些svg, woff, ttc，這樣類似的幾個(gè)文件，他們可以說是這幾個(gè)文件是你必須要加載的，具體的分散社區(qū)有相關(guān)的方案，把所有的icon，分散成一個(gè)一個(gè)的js文件，當(dāng)然里面是Svg，這樣的話如果說你是對(duì)單組件，可以單獨(dú)發(fā)布出去使用，又讓他體積最小的情況下分散的方案也是很不錯(cuò)的。
說到動(dòng)畫，可能在組件庫的維度某些組件的動(dòng)畫行為是不一樣的，比如說Tooltip和Popover，可能tooltip你hover到某個(gè)元素上馬上會(huì)就出來，但是popover就會(huì)慢一點(diǎn)，這兩者的動(dòng)畫都會(huì)有一些差別，這里面可能是有用函數(shù)定義不同的參數(shù)做一些事情。
在這塊我們是采用24柵格相對(duì)來說控制力度更細(xì)一些，（英文）現(xiàn)在是我們的柵格系統(tǒng)也是支持FLEX-BOX的，但是這個(gè)具體的來說是用LESS的循環(huán)是可以非常比較優(yōu)雅的實(shí)現(xiàn)。
但是我們的開發(fā)里面可能是對(duì)組件庫來說離不了文檔，但是在這里面是去和大家展示你的組件是什么樣的，你的不同的形態(tài)，在不同的應(yīng)用場(chǎng)景下面是什么樣的。另外是你的文檔系統(tǒng)是要把代碼貼出來，怎么樣去使用你的組件，你組件實(shí)現(xiàn)你這個(gè)效果的源碼是怎么樣的，組件的props屬性是用哪些，API 是用哪些，這個(gè)是文檔系統(tǒng)應(yīng)該做的，對(duì)于組件庫也是必不可少的，我們這里是使用自定義的vue-loader，他是會(huì)同時(shí)展示我們的DEMO和代碼，將markdown寫在vue文件里的，，我們這樣實(shí)現(xiàn)一個(gè)開發(fā)環(huán)境和調(diào)試環(huán)境還有展示站都是統(tǒng)一的效果，另外是業(yè)界很多文檔系統(tǒng)是基于md做的，我們是為什么基于vue做，因?yàn)樵趍d的代碼里面寫vue是沒有高量提示的，這個(gè)對(duì)開發(fā)體驗(yàn)是會(huì)有一定的困擾，當(dāng)然是基于md這樣的文檔系統(tǒng)復(fù)用度比較好，比如說你是使用一個(gè)react的組件庫，也可以將文檔系統(tǒng)作為一個(gè)基礎(chǔ)設(shè)施來用。
大家可以看一下我們具體的這里面的一個(gè)源碼是這么寫的，具體的代碼的書寫的方式。
文檔系統(tǒng)主要是使用了markdown的解析引擎和prismjs，這個(gè)是用來做高亮的，不像highlightjs是運(yùn)行時(shí)做的高亮，prism把markdown都PARSE成特殊的html，我們寫好相關(guān)的CSS就可以很好的去展示我們高亮的效果。另外做一些正則處理。比如說雙括號(hào)這個(gè)東西需要做一些特殊的處理，在Vue解析模板的時(shí)候就會(huì)把相關(guān)的解析結(jié)果替換掉。，這樣的話就不太好，有一些正則方面的一些處理。
我們聊一下具體的工程化，組件怎么樣提供給用戶，什么樣的形式提供給用戶，組件怎么樣做，持續(xù)集成是怎么做的。
組件要怎么提供給用戶，有兩種方式，單組件是面臨怎么樣處理公共資源的問題，比如如果你沒有把ICON分散掉的話，就是必須在你的組件是依賴ICON的，還有版本比較的問題，你整個(gè)組件庫對(duì)外提供的版本和你的單組件具體的自己做的版本升級(jí)，這樣的版本問題怎么樣處理，組件間相互依賴的問題，一個(gè)組件依賴另外一個(gè)組件，依賴的組件升級(jí)的版本，但是被依賴的組件對(duì)之前的老版本相關(guān)的依賴相當(dāng)于都得改，但是在整庫打包這塊，打成一個(gè)JS和CSS提供出去，好處是你整個(gè)組件庫是某一個(gè)版本，這樣的話對(duì)版本控制來說壓力會(huì)比較小，但是你要面對(duì)的問題是代碼大小。整個(gè)組件庫幾十個(gè)組件在一起，你怎么樣按需做這個(gè)事情，我只要加載某一個(gè)組件那怎么樣。
對(duì)于像使用webpack的項(xiàng)目而言，提供源代碼是最優(yōu)的選擇，因?yàn)樗强梢蚤_發(fā)者也是可以看到你的源代碼具體怎么實(shí)現(xiàn)的，比如說你要做一些按需也非常方便，但是對(duì)于我們的FIS，可能同學(xué)不知道有沒有聽過，是我們百度內(nèi)部的一個(gè)整體的一種前端的解決方案，可以說跟webpack存在的一些功能的重疊或者是競(jìng)爭(zhēng)，但是兩者的打包有一定區(qū)別，F(xiàn)IS里面也是會(huì)有一些按需的方案，但是使用起來有時(shí)不如webpack的那么方便。所以我們內(nèi)部這塊大多數(shù)是FIS,有一些是同時(shí)使用fis和webpack的，我們?cè)谶@塊是打包提供給用戶的。
持續(xù)集成我們這個(gè)項(xiàng)目是在github上維護(hù)，我們使用circleCI，這樣的一個(gè)系統(tǒng)，相當(dāng)于我們寫好原代碼, 一些產(chǎn)出一些展示站，組件庫的產(chǎn)出就會(huì)自動(dòng)更新，這里我們是有一個(gè)帳號(hào)，而不是一個(gè)具體的實(shí)體的人，因?yàn)檫@樣的話，這種代碼他并不是一個(gè)有意義的代碼，機(jī)器人做這個(gè)事情，在github的一些統(tǒng)計(jì)上面來說我們就會(huì)避免一些不必要的, 看上去像代碼提交的很多的情況，把這些活交給機(jī)器人的帳號(hào)。
因?yàn)檫@個(gè)時(shí)間有一點(diǎn)超了，接下來是給大家分享一些我們組件化設(shè)計(jì)相關(guān)的一些思考。
首先大家看一下這個(gè)圖，基礎(chǔ)組件到上成的分裝，這個(gè)比如說大家看具體的例子的時(shí)候會(huì)比較好理解，一個(gè)Input他需要一個(gè)Icon，比如說是要一個(gè)X的，可以把這里面的一個(gè)東西清空的，他就可以進(jìn)化成InputNumber, Suggesion, Select, Datepicker等 。所以說對(duì)于一個(gè)組件庫而言這種基礎(chǔ)組件是必不可少的，因?yàn)槿绻f沒有去做基礎(chǔ)組件的話那么比如說兩個(gè)同學(xué)直接開發(fā)一個(gè)select，開發(fā)一個(gè)datepicker，這樣的話兩個(gè)人寫的input，長的不一樣，這個(gè)是一個(gè)最直觀的痛點(diǎn)，另外一個(gè)是兩個(gè)人input他們的一些props, api也都不一樣，這樣的話我們后期維護(hù)起來的成本比較高，所以這個(gè)是定義好基礎(chǔ)組件，這個(gè)是非常重要的。
接下來是一些通用解決方案的分裝和引用，原來是動(dòng)圖這個(gè)是靜態(tài)，接下來是popper彈出層，很多組件都可以用的到，我們最后是選用popper.js的方案，可以說是位置的引擎，比如說中間這個(gè)tooltip的提示，黑色的提示，他如果說是遇到屏幕右面的時(shí)候會(huì)自動(dòng)計(jì)算的位置把他打造相反的位置就是左面。比如說右面這個(gè)select，隨著你滾動(dòng)組屏幕會(huì)自動(dòng)跑到上面去，這樣的話體驗(yàn)會(huì)比較好。
另外是基于Vue本身，我們很多跟VM打交道，我們?cè)谕ㄟ^這種插件的方式，可能是熟悉Vue的同學(xué)會(huì)比較了解他是插件的方式，使用是很方便的。如果是在我們的根節(jié)點(diǎn)APP上把組件庫作為插件引入，就會(huì)有掛載示例的方法。
比如說分散數(shù)據(jù)的方法，上下兩種方式，我可能是這樣的話是像上面的樣子直接是一個(gè)select，我在這里面相當(dāng)于是用這個(gè)data，比如說LI這個(gè)東西模擬option這個(gè)方式，這樣的話就是說我降低了自定義的能力，比如說想對(duì)這里面的option做一些樣式的處理，或者是做一些數(shù)據(jù)上的處理，都做不到了，所以如果說是這里面提供的這個(gè)來說，第二個(gè)方式是會(huì)比第一個(gè)方式自定義能力要強(qiáng)一些。
下面是具體對(duì)今天說的內(nèi)容做一些總結(jié)。
首先是技術(shù)和方法論在組件庫這塊，要做具體的深入的調(diào)研，做一些取舍，相關(guān)的規(guī)范一定是要對(duì)團(tuán)隊(duì)的相關(guān)的成員做一些約束的，相關(guān)的工作流程與團(tuán)隊(duì)成員做一些培訓(xùn)。
組件庫這個(gè)坑是比較大的，除了我們純粹的寫組件之外一些文件系統(tǒng)，持續(xù)集成，我前面提到的之外，比如說是像測(cè)試一些相關(guān)的工具鏈，一些國際化相關(guān)的東西，如果說你要做一些特別大的開源組件庫也是不可避免的，一些附帶的資源，比如說他可以反哺一些UI的設(shè)計(jì), 可以參考這種組件庫的相關(guān)的交互。今天大概的內(nèi)容就到這，插播一條，我們現(xiàn)在外賣的前端也是在招聘，我們現(xiàn)在做的業(yè)界比較新的技術(shù)都會(huì)在使用，比如說vue, react, react-native, nw.js等等，而且我們的技術(shù)氛圍很濃厚的，大家可以考慮一下，這個(gè)是我郵箱，給大家推薦一個(gè)公眾號(hào)，百度外賣技術(shù)團(tuán)隊(duì)的公眾號(hào)，大家可以掃二維碼 關(guān)注，會(huì)經(jīng)常的發(fā)一些技術(shù)的文章大家可以關(guān)注一下。
