家晚上好，今天很高興能夠參加我們百度外賣和IT168聯合舉辦的百度外賣技術分享季的主題的活動，今天我這塊是第一期，后面還會有其它的百度外賣的一些技術大牛會分享后端、測試等一系列的技術性的話題，也歡迎大家繼續來關注我們的百度外賣技術分享季，話不多說，就進入我們今天晚上的主題。

今天我們講的這個主題是從零到一的組件庫的設計與實踐，大家看這個主題應該就非常清楚，作為一個前端工程師來說平常的開發是離不開組件庫的，大家非常熟悉比如像Ant Design、Element這樣的組件庫，但是如何自己設計一個組件庫，或者是怎么樣是最佳的實踐，今天就打算借這次分享的機會和大家分享一下百度外賣這方面的心得。

先做一下自我介紹，我叫朱翀宇，來自百度外賣的商業平臺部，之前是在百度地圖這邊做前端的相關的工作，現在是在商業平臺相關的前端開發和一些技術調研的工作。

這個是我們自己實現的基于Vue的github的組件庫，這是地址，大家有興趣的話可以看一下，雖然是在github上維護，但是我們基本上是在內部使用的，所以說對外也沒有做特別多的宣傳。

這個組件庫現在的情況是有三十多個PC端的組件，對應大概有十來個同學先后對這個庫有相關的貢獻，就是這樣。

回到我們今天的話題，怎么樣去從零到一搭建一個屬于我們自己的組件庫，這個是我們今天具體的內容，首先是認知和目標，組件庫的規劃，具體的架構設計和實踐，最后是組件化方面的設計的思考。

我們開始，首先是從認知和目標開始，首先要做一個組件庫必須先明白我們具體做的是哪些東西。

這塊是具體包括何謂組件庫，組件庫是什么概念，我們為什么做這個組件庫，具體的收益是什么，因為我們大家都在公司里面，做的相關的事情也是對公司產生一定的收益，具體能做嗎，或者是我們需要做成什么樣，怎么樣去做，怎么樣的時候何時去完成。

首先回到組件這個話題，可能很多同學在平時開發的時候會寫一些組件，我們稱這樣的組件為單組件，主要的特點是沒有什么限制，比如說我們組件是分為html,js,css這幾塊，如果是自己寫一個組件就不需要太多的限制，但是如果說是去實現一個組件庫你要對整個組件庫的形態，長什么樣，相關的命名，一些開發規范，一些視覺交互的效果，具體使用的方式這塊都需要有一定的統一的或者是統籌的考慮。

可能有的同學會說我直接開始寫代碼就可以了，但是這里面就需要強調的一點，組件庫這塊不僅僅是技術，還有方法論，方法論是非常重要的。這個方法論后面是會具體的和大家去解釋。

在我們的前端可能會有一句話，當一個新的輪子出來的時候，前端要把實現的東西再實現過一次，這個是要追溯一些歷史，最早的大家要用一些操作DOM的相關的庫去實現前端的需求，現在是一些MVVM框架，比如說我們的Vue, React這些相關的框架去實現這個東西，現在來說是FRP在這種編程上可能也是會有一些相應的實踐，但是FRP這塊能否成為未來的標準還是需要時間的檢驗，不管怎么樣在任何的一個階段我們都需要去實現過N次的東西，可能就是組件，組件是可以提高我們的具體的開發效率的，但是對于任何具體的框架而言，對于組件來說都是必不可少的。

我們開始講上面說的方法論相關的事情，很重要的事情是對的時間去做對的事情，為什么要這么說，你一開始去想做一個組件庫的時候，一定要三思，大家這個應該很好理解的，比如說對技術棧的生命周期，發展的趨勢，比如說我現在可能不會基于Backbone這種已經過時，或者是比較落后，或者是流行度不是特別高的框架去做組件庫。另外，還要考慮我們業務的需求。

現在我們做這些組件肯定是要反哺業務的，如果業界或者是相關的社區已經有很優秀的輪子了，你又重復造輪子或者是你做出來的東西還是跟別人有一定的差距的話，你的投入就會顯得沒有具體的產出，另外是團隊的構成，比如說同學他是否掌握具體的相關的技術，或者是團隊同學對于一些技術棧的偏好之類的，這些事情也是對我們具體做這個事情也是有影響的。

我們具體的目標，當時我們做具體的這個組件庫的時候，目標一定要明確，內容是一個基礎的組件庫，就是他是沒有任何業務相關的邏輯，因為我們做組件庫是強調復用，業務的邏輯是經常變化的，但是基礎組件的交互是比較固定的，另外是組件的數量，整個庫的容量是多少，具體的形態是什么樣的，分發，以那種方式提供給用戶，用戶是可以使用一些其它的拷貝或者是線上資源方式，另外是維護人力流程這塊。

接下來我們就開始說一下具體的在做這件事情之前具體怎么樣對組件庫做一個規劃。

我們說規劃的核心是什么，實際上是兩個字是取舍，取舍是做什么事情不做什么事情，具體是怎么樣分工，具體的時間怎么安排。

我們這個組件庫是做技術組件庫，不做業務組件庫，我們做高頻的組件，一定是在我們的業務里面做比較高頻的組件我們才會考慮開發，可能是業務里用的比較小眾的情況下就不會選擇開發，還有一點沒有框架的依賴，比如說jquery等 。。為什么沒有框架依賴，相關的框架會增加我們體系的大小，另外組件庫本身不應該有具體的傾向性的，因為它是面向開發者的，如果組件庫有相關的傾向性很可能會對開發者造成一定的困擾。

說一下分工這塊，我們組件庫是一個團隊合作的項目，這個組件庫是聚焦在幾個人身上做還是大家每個人有一個這樣的情況，首先我們是覺得是需要結合一些業務項目的情況，我們不能專職做這個東西，平時有業務的開發，我們要保證投入，通過一些相關的設計方式我們正式質量的差異，另外我們要落實具體的規范。

那接下來是落實具體的規范就給和大家分享一下我們相關的組件庫的規范。這個事情是對組件庫來說顯得尤其的重要，因為組件庫有可能是一個團隊協作的產物，或者組件庫本身是一個整體，必須要有相關的規范。

我們認為組件庫這塊的規范有很多，總結了一下，比如說評審的規范，這個組件庫應該是什么樣的，API怎么設計，或者是屬性相關的東西應該怎么設計，評審的規范，另外是代碼的規范，代碼應該有什么，遵循一個什么樣的代碼規范，另外是開發的規范，大家開發的模式是一樣的，最后把這個規范，因為組件庫本身是生態最后肯定離不開做維護，相應的維護也是系統規范的。

首先這個是一個基本的規范，大家可以看上一頁的圖，代碼的規范和開發的規范，這一部分是在組件庫本身的維度上面我們可以對他做一些約束，首先是在我們的開發規范里面具體的，我們是用ES6去做，ESLINT使用我們百度的具體的代碼的規范，相關的東西大家可以去到我們百度FEX的github庫中搜到，做一些規范檢查，我們最后的CSS的語言是使用的LESS，說到規范，大家可能有一些同學知道會有一些，比如說是OOCSS，BEM這些規范，這種規范現在在社區內的意見并不是非常統一，現在的框架，比如說Vue可以通過scope把組件Css與外部給隔離掉，或者是CSS IN JS這種相關的技術給他可以做到，去隔離這種CSS的污染，像BEM的規范，實際上是會增加一些相關開發的負擔，因為他是跟組件本身是一個平行的狀態。

在命名的規范這塊是可能對于我們組件庫來說，有具體的組件名，具體的API相關的都會涉及到命名，實際上這也是一個比較難的一個事情，因為首先你需要簡明扼要還要統一，相對來說就是每個平行的組件，類似的名稱是要統一的，肯定要語義化，方便開發者去理解，還要貼近我們原生的相關的命名。

貼一些例子，就是大家可能是可以看到這上面的一些，比如說我們列舉的一些好的例子與不好的例子，大家可以看一下。

對組件庫來說他是基于一個框架相關的，比如說像Ant Design他是屬于一個React相關的組件庫，Element是基于Vue開發的，首先這些框架本身的思想是不盡相同的，相關的開發范式也是不盡相同的，這些也是針對框架做不同的規范。

舉個例子，比如說在Vue對你定義的一些數據做一些簡單的處理，表達式說清楚就不必要計算屬性/method這種具體在代碼里寫的東西，這個也是我們推薦的方式。

最后是開發規范，當然有一些同學喜歡用html/css/js三個文件這種方法，我們統一定的文件的方式，首先他是可以和webpack很好的去做一個相應的解析，我們這種底層的具體的做打包或者是做相關開發的東西都是用webpack.另外樣式分離我們不會在Vue去寫，我們單獨的把樣式抽離出來，能夠更統一的使用相關的一些LESS變量，會比較方便，我們還要統一一些工具庫，DOM操作，通信相關的一些庫，我們會統一具體的動畫庫，動畫庫在Vue里面就是trasition.還要統一開發環境和展示站，最后維護就是我們提交的是使用github這種相關的工作流，。

上面可能是說了很多類似是規劃和規范相關的東西，我們之前說的方法論相關的一些。下面是著重給大家介紹一下具體的架構設計和工程化這塊的內容。

大家可能是可以打開看一下這個圖，這個是我們的一個具體的結構的設計，大家看下面的紫色的這部分是我們具體的組件的一個容器，包括我們的Assets,比如說圖片字體這些的靜態資源，DEMO這個是專門寫組件的文檔的，對于每一個組件是一個單文件的Vue，我們CSS剛才說了已經是分離出去了，相關的一些工具庫和一些相關的Mixin，左邊這塊是一個單頁，我們的組件肯定是需要有一個展示站的單頁，這塊我們的開發環境和我們的文檔是統一的，肯定是離不開為這個組件庫寫文檔。

但是在開發過程中又離不開比如說調試，我們把這兩個過程合在一起了，這一切都是通過webpack來做，可能大家比較熟悉了，在發版這邊是發布到具體的NPM上去做，在最右面這塊是一個持續集成，就是在我們提交代碼的時候，我們不用去手動的build dist, 這個是我們提供給用戶的一個具體打包完成之后的具體的文件，我們不希望每一次手動的build，另外是展示站這塊你改了一個文檔，你希望可以自動的更新，這塊也是在持續集成的工作。

在說一下我們的CSS架構相關的，首先之前我們提到過我們是用這種語言寫的，預處理，首先是需要一個環境適應性，當前只在組件的內部去產生生效，不會被其它的東西污染，還要具體的相關的交互是要統一的。我們的主題是可以更換的。另外是一些其它的高度的自定義，這塊是提到一個Bootstrap, 這個東西大家很熟悉，就是可能是很多同學并沒有深入利用好他的實踐，就是這個庫的話內部的實現是比較精妙的，具體的我是建議大家可以看看這個原碼，我們這塊的實現也是去參考了Bootsrap，有一些同學會問為什么你們不直接基于Bootstrap來做，我們最開始的時候我們的確是基于這個做的，但是后面實際上會發現一些問題，比如說如果說你本身的站點原來大量使用Bootstrap的話, 可能是會對這個做一些自己的定義，比如說是btn-info這樣的類名可能會被做一些自定義，如果我們在這里面直接使用這個類名肯定是會被污染的。對于關于具體的我們這個長什么樣，很大程度上是由我們CSS決定的，如果你一開始做一個組件庫的話，如果說你是一個前端或者是你是一個設計都很擅長的同學，你可以自己搞一套，但是對于很多前端工程師不是非常懂設計語言或者是其它的情況下最好是參照一些業界已有的語言，比如說像Material Design, Ant Design這樣的設計語言。

大家可以打開這個圖看一下，這個是一個CSS具體的結構，首先是左邊是基礎相關的東西，可能是一些CSS的，比如說Noramlize, Reset做一些基礎的工作，我們定義相關的顏色相關的字體，圖標，grid柵格相關的東西。

中間可能是一些Mixin, 就是對一些兼容性寫法做比較簡便的處理，最右面我們定義了一些過渡，這幾種是包含了絕大多數組件相關的動畫，在Vue里面他是一個transition, React里面也會有相關的動畫組件方案，主要都是在我們一個過渡，定義了幾個階段。比如說enter, leave類似具體的階段做具體的事情。

在顏色的話對于組件庫來說肯定是會定義一個主色，另外一個是info是體現一個信息傳遞，success體現一個信息的成功或者是一個操作的成功，warning體現一個警告，error體現一個錯誤的操作，類似的這些基本色一定要定義好。在我們從黑到白定義的一些比如說是灰度方面的顏色，less相關的函數是可以實現的。

另外在右邊這塊是基于你的主色你可以通過這種相關的方式對他做一些操作，這樣的話會具體的衍生出一些顏色，具體的這些顏色是他用這些事情可以換膚，就是主題色的改變，可以粗略的這么理解，我們如果把主色一改，所有的組件的顏色相當于都會有做相應的改變。

圖標這塊是先想說一個問題，LICENCE是很重要的，看他是不是MIT的，如果是一些付費或者是商業使用某些圖標是不讓你用的，雖然我們做的是內部的組件庫，我們在github上做這個事情，所以我們是使用開源的圖標庫，第二個是字體的資源的打包或者是分散，比如說字體大家應該很熟悉，現在的icon字體會有一些svg, woff, ttc，這樣類似的幾個文件，他們可以說是這幾個文件是你必須要加載的，具體的分散社區有相關的方案，把所有的icon，分散成一個一個的js文件，當然里面是Svg，這樣的話如果說你是對單組件，可以單獨發布出去使用，又讓他體積最小的情況下分散的方案也是很不錯的。

說到動畫，可能在組件庫的維度某些組件的動畫行為是不一樣的，比如說Tooltip和Popover，可能tooltip你hover到某個元素上馬上會就出來，但是popover就會慢一點，這兩者的動畫都會有一些差別，這里面可能是有用函數定義不同的參數做一些事情。

在這塊我們是采用24柵格相對來說控制力度更細一些，（英文）現在是我們的柵格系統也是支持FLEX-BOX的，但是這個具體的來說是用LESS的循環是可以非常比較優雅的實現。

但是我們的開發里面可能是對組件庫來說離不了文檔，但是在這里面是去和大家展示你的組件是什么樣的，你的不同的形態，在不同的應用場景下面是什么樣的。另外是你的文檔系統是要把代碼貼出來，怎么樣去使用你的組件，你組件實現你這個效果的源碼是怎么樣的，組件的props屬性是用哪些，API 是用哪些，這個是文檔系統應該做的，對于組件庫也是必不可少的，我們這里是使用自定義的vue-loader，他是會同時展示我們的DEMO和代碼，將markdown寫在vue文件里的，，我們這樣實現一個開發環境和調試環境還有展示站都是統一的效果，另外是業界很多文檔系統是基于md做的，我們是為什么基于vue做，因為在md的代碼里面寫vue是沒有高量提示的，這個對開發體驗是會有一定的困擾，當然是基于md這樣的文檔系統復用度比較好，比如說你是使用一個react的組件庫，也可以將文檔系統作為一個基礎設施來用。

大家可以看一下我們具體的這里面的一個源碼是這么寫的，具體的代碼的書寫的方式。

文檔系統主要是使用了markdown的解析引擎和prismjs，這個是用來做高亮的，不像highlightjs是運行時做的高亮，prism把markdown都PARSE成特殊的html，我們寫好相關的CSS就可以很好的去展示我們高亮的效果。另外做一些正則處理。比如說雙括號這個東西需要做一些特殊的處理，在Vue解析模板的時候就會把相關的解析結果替換掉。，這樣的話就不太好，有一些正則方面的一些處理。

我們聊一下具體的工程化，組件怎么樣提供給用戶，什么樣的形式提供給用戶，組件怎么樣做，持續集成是怎么做的。

組件要怎么提供給用戶，有兩種方式，單組件是面臨怎么樣處理公共資源的問題，比如如果你沒有把ICON分散掉的話，就是必須在你的組件是依賴ICON的，還有版本比較的問題，你整個組件庫對外提供的版本和你的單組件具體的自己做的版本升級，這樣的版本問題怎么樣處理，組件間相互依賴的問題，一個組件依賴另外一個組件，依賴的組件升級的版本，但是被依賴的組件對之前的老版本相關的依賴相當于都得改，但是在整庫打包這塊，打成一個JS和CSS提供出去，好處是你整個組件庫是某一個版本，這樣的話對版本控制來說壓力會比較小，但是你要面對的問題是代碼大小。整個組件庫幾十個組件在一起，你怎么樣按需做這個事情，我只要加載某一個組件那怎么樣。

我們在這的取舍，我們具體的使用環境而定的，我們這種主要的用戶，因為是一個內部組件庫，我們主要運行環境是一個內部的平臺，在內部的平臺上內部的PC平臺，在這個情況下，我們的組件比如說壓縮完以后是完全不會有什么帶寬方面或者是加載速度方面的瓶頸，所以最后我們是用整庫打包的方式。

對于像使用webpack的項目而言，提供源代碼是最優的選擇，因為他是可以開發者也是可以看到你的源代碼具體怎么實現的，比如說你要做一些按需也非常方便，但是對于我們的FIS，可能同學不知道有沒有聽過，是我們百度內部的一個整體的一種前端的解決方案，可以說跟webpack存在的一些功能的重疊或者是競爭，但是兩者的打包有一定區別，FIS里面也是會有一些按需的方案，但是使用起來有時不如webpack的那么方便。所以我們內部這塊大多數是FIS,有一些是同時使用fis和webpack的，我們在這塊是打包提供給用戶的。

持續集成我們這個項目是在github上維護，我們使用circleCI，這樣的一個系統，相當于我們寫好原代碼, 一些產出一些展示站，組件庫的產出就會自動更新，這里我們是有一個帳號，而不是一個具體的實體的人，因為這樣的話，這種代碼他并不是一個有意義的代碼，機器人做這個事情，在github的一些統計上面來說我們就會避免一些不必要的, 看上去像代碼提交的很多的情況，把這些活交給機器人的帳號。

因為這個時間有一點超了，接下來是給大家分享一些我們組件化設計相關的一些思考。

首先大家看一下這個圖，基礎組件到上成的分裝，這個比如說大家看具體的例子的時候會比較好理解，一個Input他需要一個Icon，比如說是要一個X的，可以把這里面的一個東西清空的，他就可以進化成InputNumber, Suggesion, Select, Datepicker等 。所以說對于一個組件庫而言這種基礎組件是必不可少的，因為如果說沒有去做基礎組件的話那么比如說兩個同學直接開發一個select，開發一個datepicker，這樣的話兩個人寫的input，長的不一樣，這個是一個最直觀的痛點，另外一個是兩個人input他們的一些props, api也都不一樣，這樣的話我們后期維護起來的成本比較高，所以這個是定義好基礎組件，這個是非常重要的。

接下來是一些通用解決方案的分裝和引用，原來是動圖這個是靜態，接下來是popper彈出層，很多組件都可以用的到，我們最后是選用popper.js的方案，可以說是位置的引擎，比如說中間這個tooltip的提示，黑色的提示，他如果說是遇到屏幕右面的時候會自動計算的位置把他打造相反的位置就是左面。比如說右面這個select，隨著你滾動組屏幕會自動跑到上面去，這樣的話體驗會比較好。

另外是基于Vue本身，我們很多跟VM打交道，我們在通過這種插件的方式，可能是熟悉Vue的同學會比較了解他是插件的方式，使用是很方便的。如果是在我們的根節點APP上把組件庫作為插件引入，就會有掛載示例的方法。

比如說分散數據的方法，上下兩種方式，我可能是這樣的話是像上面的樣子直接是一個select，我在這里面相當于是用這個data，比如說LI這個東西模擬option這個方式，這樣的話就是說我降低了自定義的能力，比如說想對這里面的option做一些樣式的處理，或者是做一些數據上的處理，都做不到了，所以如果說是這里面提供的這個來說，第二個方式是會比第一個方式自定義能力要強一些。

這也是說把這種通過拆分組件降低了這個耦合，這個是通過slot的方式去實現。

下面是具體對今天說的內容做一些總結。

首先是技術和方法論在組件庫這塊，要做具體的深入的調研，做一些取舍，相關的規范一定是要對團隊的相關的成員做一些約束的，相關的工作流程與團隊成員做一些培訓。

組件庫這個坑是比較大的，除了我們純粹的寫組件之外一些文件系統，持續集成，我前面提到的之外，比如說是像測試一些相關的工具鏈，一些國際化相關的東西，如果說你要做一些特別大的開源組件庫也是不可避免的，一些附帶的資源，比如說他可以反哺一些UI的設計, 可以參考這種組件庫的相關的交互。今天大概的內容就到這，插播一條，我們現在外賣的前端也是在招聘，我們現在做的業界比較新的技術都會在使用，比如說vue, react, react-native, nw.js等等，而且我們的技術氛圍很濃厚的，大家可以考慮一下，這個是我郵箱，給大家推薦一個公眾號，百度外賣技術團隊的公眾號，大家可以掃二維碼 關注，會經常的發一些技術的文章大家可以關注一下。