UI組件庫和靜態(tài)服務(wù)域的相關(guān)實(shí)踐

這是一篇懶散的隨筆，寫作時(shí)，完全沒有考慮到讀者的感受，僅僅是作者對(duì)UI和組件化等topic的一些胡思亂想。勿噴。

我一直覺得，一個(gè)有逼格、有深度的公司，應(yīng)該在UI這塊有自己的一套規(guī)范，無論是從0到1自己實(shí)現(xiàn)的也好，還是站在巨人的肩膀上。

人都有身不由己的時(shí)候，無論碼農(nóng)還是設(shè)計(jì)師們。在這樣一個(gè)背景下，往往做出一些割裂的產(chǎn)品和設(shè)計(jì)。比如，UI風(fēng)格混亂、交互風(fēng)格混亂、特效混亂、代碼混亂……

We need rules.

試想一下，如果你處在下圖的工作場(chǎng)景中，

這里的Nyx即是我們的UI規(guī)范。

1，產(chǎn)品在產(chǎn)出需求原型時(shí)，在展示和交互部分，會(huì)借鑒參考UI規(guī)范。把合適的UI放在合適的原型展示上。
2，設(shè)計(jì)師們拿到原型后，參考UI規(guī)范，做出視覺稿。
3，前端開發(fā)在拿到視覺稿之后，使用UI規(guī)范的組件實(shí)現(xiàn)，快速實(shí)現(xiàn)。

Perfect!

這期間可能會(huì)有一些坑在里面，但是我認(rèn)為這個(gè)思想和方向應(yīng)該是沒有問題的。

那么問題來了，我們?cè)撛趺醋觯?/p>

1，想好了，我們到底應(yīng)該是站在巨人的肩膀上？還是自己要做巨人？這關(guān)系到，我們到底是選一套主流的UI作為底層基礎(chǔ)UI，還是應(yīng)該自己造一個(gè)。兩種方案各有優(yōu)劣，我個(gè)人傾向后者。因?yàn)槲乙粋€(gè)信奉拿來主義的人。
2，選好了底層的基本UI庫之后，我們仔細(xì)研讀，弄清楚它每一個(gè)部分。為什么需要這么做？一個(gè)字，避坑。
3，這時(shí)候需要我們的設(shè)計(jì)師兄弟上場(chǎng)了。前端開發(fā)們與之親密合作，目的只有一個(gè)，那就是決定好我們到底需要哪些基本的UI。更進(jìn)一步，我們還需要決定這些基礎(chǔ)UI長成什么樣子?；綰I的本質(zhì)應(yīng)該是一堆CSS文件。
4，好了，這時(shí)候我們已經(jīng)有了基礎(chǔ)UI了，這時(shí)候我們可以動(dòng)一動(dòng)組件的心思了。

有一個(gè)問題來了，什么是組件？組件跟之前提到的UI又是什么關(guān)系？

我的腦海里，UI指的是頁面元素的表現(xiàn)風(fēng)格，它是一套規(guī)范，它規(guī)定了頁面元素應(yīng)該如何表現(xiàn)自己。而組件是對(duì)UI規(guī)范的一種多樣化實(shí)現(xiàn)。

舉個(gè)例子來說，一個(gè)按鈕的UI規(guī)范可能是這樣的：是一個(gè)矩形，中間有文本，邊界有邊框，可以點(diǎn)擊，點(diǎn)擊的時(shí)候會(huì)有一種特殊的視覺效果，……

那么，與之對(duì)應(yīng)的按鈕組件，我們可以抽象出來很多參數(shù)，根據(jù)需求來自定義按鈕的UI，并且把這些參數(shù)都量化成代碼實(shí)現(xiàn)。

組件更多的內(nèi)容，我們后面還會(huì)繼續(xù)探討?，F(xiàn)在，言歸正傳。

5，我們現(xiàn)在有了UI和組件，我們可以做更多的事情了。我們以UI和組件為基礎(chǔ)，搭建上層的靜態(tài)域，為業(yè)務(wù)域提供服務(wù)。怎么理解這句話？

這里有一張圖，

簡單概括來說，我們會(huì)一個(gè)稱之為靜態(tài)域的東西，為所有的其他的業(yè)務(wù)域提供通用的UI和交互服務(wù)支持，包括但不限于靜態(tài)文件分發(fā)、UI及組件化支持、通用頁面版本支持等等。

所以，接下來讓我們來具體的量化一下我們的計(jì)劃。

0，準(zhǔn)備階段

1. 在做這些事之前，我們應(yīng)該自問三個(gè)問題，為什么要做？解決什么問題？目標(biāo)是什么？
2. 敲定底層方案的選型和實(shí)現(xiàn)方式。
3. 相關(guān)規(guī)范和計(jì)劃的制定。

我覺得到文章這里，我們應(yīng)該已經(jīng)準(zhǔn)備好了。

1，第一階段

1. 基礎(chǔ)UI的抽象及分類。
2. 構(gòu)建底層的CSS基礎(chǔ)代碼。
3. UI的派生繼承方式及實(shí)現(xiàn)。
4. UI多態(tài)化抽象。

關(guān)于UI分類，參考了很多前輩的成果，如下圖

個(gè)人覺得按照這種feature的概念和維護(hù)隊(duì)UI做分類可能更具延展性和拓展性。

關(guān)于底層CSS基礎(chǔ)代碼的構(gòu)建，我覺得bootstrap是一個(gè)不錯(cuò)的做法，提供一個(gè)可供高度自定義的用戶編譯界面。

此階段中，我們還會(huì)做一些UI多態(tài)化的工作。什么是UI多態(tài)化？舉一個(gè)簡單的例子，你是一個(gè)按鈕。你可以是紅的，你可以綠的，你還可以是黑的；你可以胖胖的，你還可以很苗條；你可以是高富帥，也可以是矮矬窮。

同一類的UI可以擁有不同維度的變化，比如顏色、大小、交互特性等等。

正式因?yàn)閁I的多態(tài)性，給了我們豐滿的UI展示。

2，第二階段

1. 基礎(chǔ)UI的動(dòng)效及分類。
2. 實(shí)現(xiàn)UI動(dòng)效（漸進(jìn)增強(qiáng)）。
3. UI多態(tài)化實(shí)現(xiàn)。
4. 多終端支持

如果你的頁面自帶各種酷炫的動(dòng)效，相比樸素的UI，你無疑會(huì)更加被人青睞。但是動(dòng)效何其多，我們需要需要給不同種類的UI裝備合適的動(dòng)效，以達(dá)到完美契合度。本人是十分厭惡無腦濫用動(dòng)畫的。合適的就是最好的。

此外，我們?cè)趯?shí)現(xiàn)動(dòng)效的時(shí)候，還有一個(gè)準(zhǔn)則，就是漸進(jìn)增強(qiáng)。而且全部都依賴CSS3，我們不會(huì)使用Javascript來操作dom來實(shí)現(xiàn)某一些動(dòng)畫效果，絕不。簡而言之，那些不支持CSS3的可憐瀏覽器們，只能注定被扔在矮矬窮的陣營里面了。

此階段中，我們還是把UI多態(tài)化的task做掉。一般來說，會(huì)有兩種做法，一種是獨(dú)立式的css實(shí)現(xiàn)方式，一種是堆疊式的css實(shí)現(xiàn)方式。比如，

<div class="btn-butcher"></div>
<div class="btn btn-green btn-large"></div>

兩者都表示綠胖子。明顯的，后者具有更強(qiáng)的定制化，更加靈活。

關(guān)于多終端。在這之前，我們都應(yīng)該了解一下，什么是響應(yīng)式設(shè)計(jì)（Responsive design，RWD）？什么是自適應(yīng)設(shè)計(jì)（Adaptive design，AWD）？

舉一個(gè)例子。一個(gè)頁面，如果無論你如何的縮放瀏覽器的窗口大小，這個(gè)頁面都會(huì)較好的展現(xiàn)。那我們就說這個(gè)頁面是響應(yīng)式的。
如果你用不同尺寸的設(shè)備去訪問這個(gè)頁面，它也能非常自如在不同的設(shè)備展現(xiàn)，此時(shí)，我們就說這個(gè)頁面是自適應(yīng)的。

• RWD：傾向基于Media Queries、Content-Based Breakpoint來改變頁面適配不同的分辨率尺寸。
• AWD：傾向針對(duì)幾種特定的分辨率尺寸做定制。可能會(huì)有好幾套頁面。

但是在有時(shí)候，他們又會(huì)相會(huì)滲透，配合使用。

3，第三階段

1. 組件化實(shí)現(xiàn)方式的探索，如何組合UI和交互？
2. 構(gòu)建基礎(chǔ)組件及組件分類
3. 構(gòu)建復(fù)雜組件及交互實(shí)現(xiàn)

前面已經(jīng)說到了，組件是對(duì)UI的具體實(shí)現(xiàn)。UI是一套規(guī)范，要想將這一套組件轉(zhuǎn)變成組件，我們需要思考一件非常重要的事，就是：如何將UI實(shí)現(xiàn)為組件？我的意思是，實(shí)現(xiàn)的途徑是什么？

想要回答這一個(gè)問題，先得回答一個(gè)前提問題？我們?cè)趺慈ザx一個(gè)組件？言下之意，一個(gè)組件，應(yīng)該包含什么內(nèi)容？

現(xiàn)下，普遍的一種觀點(diǎn)認(rèn)為，一個(gè)組件應(yīng)該包含三部分，展現(xiàn)載體（模板）+ 視覺展示（樣式）+ 交互特性（交互）這三部分組成。

基本上我們前面說的UI指代就是模板 + 樣式。所以，我們現(xiàn)在還缺一點(diǎn)，我們?nèi)绾谓o組件引入交互？

我們需要一個(gè)世界觀去架構(gòu)模板、式樣和交互，讓他們有機(jī)的組合在一起。我來看看react是如何做組件化的。

從圖中我們可以看出，

1. 要有良好的類繼承機(jī)制。
2. 需要方便的引入機(jī)制。包括引入自身的樣式，也包括引入別的組件。
3. 需要一個(gè)接口對(duì)外暴露組件自身。

我們的組件化最少也需要從這三個(gè)方面考慮?；蛘呶覀兺耆梢圆捎胷eact為實(shí)現(xiàn)載體也并無不可。

4，第四階段

1. 什么是靜態(tài)域？解決什么問題？
2. 靜態(tài)資源分發(fā)，UI和組件支持。
3. 業(yè)務(wù)域中通用界面和操作的統(tǒng)一支持。
4. ……

所謂靜態(tài)域，其實(shí)就是在UI庫和組件化這兩者較為完備之后，我們?yōu)榱俗孶I和組件的服務(wù)輸出更加智能和高效，從而搭建的一種上層應(yīng)用。他的具體作用，我覺得這張圖完全可以意傳了。

除了靜態(tài)資源分發(fā)，UI和組件支持這一點(diǎn)之外，業(yè)務(wù)域中通用的板塊也可以使用靜態(tài)域來做分發(fā)。舉個(gè)例子，有一個(gè)管理中心的用戶后臺(tái)，這個(gè)管理中心是好幾個(gè)業(yè)務(wù)線控制臺(tái)的聚合體。它會(huì)有一個(gè)左側(cè)導(dǎo)航菜單，每一個(gè)菜單對(duì)應(yīng)各自業(yè)務(wù)的頁面。我們?cè)谑菍?shí)現(xiàn)上，可能會(huì)在每一個(gè)獨(dú)立的業(yè)務(wù)域中都做一套這個(gè)左側(cè)菜單，一旦某個(gè)菜單項(xiàng)發(fā)生更新，將會(huì)影響到所有包含這個(gè)左側(cè)菜單的業(yè)務(wù)域。這無疑是一個(gè)很爛的方案。

假如我們靜態(tài)域已經(jīng)可以提供服務(wù)了，那么不同的業(yè)務(wù)域甚至只要調(diào)用業(yè)務(wù)域的一個(gè)js腳本就可以在各個(gè)業(yè)務(wù)域中生成左側(cè)菜單了。

perfect!

終于嘮叨完了。