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

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

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

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

We need rules.

試想一下，如果你處在下圖的工作場景中，

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

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

Perfect!

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

那么問題來了，我們該怎么做？

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

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

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

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

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

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

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

這里有一張圖，

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

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

0，準備階段

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

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

1，第一階段

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

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

個人覺得按照這種feature的概念和維護隊UI做分類可能更具延展性和拓展性。

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

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

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

正式因為UI的多態(tài)性，給了我們豐滿的UI展示。

2，第二階段

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

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

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

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

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

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

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

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

• RWD：傾向基于Media Queries、Content-Based Breakpoint來改變頁面適配不同的分辨率尺寸。
• AWD：傾向針對幾種特定的分辨率尺寸做定制?？赡軙泻脦滋醉撁?。

但是在有時候，他們又會相會滲透，配合使用。

3，第三階段

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

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

想要回答這一個問題，先得回答一個前提問題？我們怎么去定義一個組件？言下之意，一個組件，應(yīng)該包含什么內(nèi)容？

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

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

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

從圖中我們可以看出，

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

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

4，第四階段

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

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

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

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

perfect!

終于嘮叨完了。