本文屬于波瀾不驚，平鋪直敘版本。如果想看有激情有思想的版本，可以去ISUX官博：“順勢而為，HTML發展與UI組件設計進化”，多多留言哈。
一、基于HTML開發組件的設計思想
要想知道基于原生的HTML進行UI組件開發是什么鬼，您可以狠狠地點擊這里：基于原生的HTML UI組件體驗demo
點擊上面的demo, 進入一個平凡的靜態頁面，引入眼簾的是一個普通的表單，里面的UI都是系統默認的，HTML功能也是原生的。
例如：
- title提示
- 選擇日期
- 點擊提交的表單驗證
UI雖然原始，但是功能卻很健全。
例如：
- 男女款式、城市以及運費險對價格的影響
- 表單提交事件
下面，就是奇跡出現了，點擊demo頁面(下圖所示)的按鈕進行某項目UI組件資源的加載和初始化：
結果，一瞬間，上面原始粗糙的界面一下子變成了這樣子：
妥妥的丑小鴨變成了白天鵝，包括之前原生的HTML功能。
例如：
- title提示
- 選擇日期
- 點擊提交的表單驗證
而，最最重要，和最最神奇的事情是：我們僅僅是引入了UI組件的一些CSS和JS，對，僅僅是引入和一點初始化，沒有動之前一點點一絲絲的業務JS. 但是，之前的各種交互功能，卻完全不受影響，反而體驗更上兩層樓!
請看下面的gif截圖演示：
之所以這里的UI組件可以和業務相關JavaScript完全分離，同時可以無縫對接。就是因為設計理念上是基于原生的HTML實現的，讓UI組件回歸其本質或者說本職作用——UI.
二、基于原生HTML的UI組件開發
解決2個疑問：
-
為何可以基于原生HTML進行UI組件開發?
-
如何基于原生HTML進行UI組件開發?
1. 為何可以基于原生HTML進行UI組件開發?
HTML中自帶的很多原生的UI表現，UI組件的UI表現本質上是類似的，差別僅僅在于長相的粗糙和精致。
舉個例子，title提示。瀏覽器默認使用title屬性，長這樣：
而設計師設計的tips組件是小黑風格，如下：
這兩者其實是一個東西，作用是一樣的，差別僅僅在于——UI. 因此，我們完全可以基于原生的title屬性實現我們的tips提示效果。利用相同的本質，改變的僅僅是呈現的樣子。
再舉個更有意思的例子，表單驗證。在HTML5中，表單默認內置驗證，基于type, required, pattern, max, min等HTML原生屬性，且自帶UI(下圖是win下Chrome效果，其他系統其他瀏覽器長相不一樣):
下圖則是team決定采用的UI形式：
同樣的，驗證的本質都是類似的，交互的形式也是類似的，不一樣的僅僅是UI. 因此，我們完全可以基于原生的HTML驗證規則實現我們的表單驗證效果。利用相同的本質，改變的僅僅是呈現的樣子。
其他很多UI組件都是類似的。
當我們希望改變的僅僅是相貌的時候，重復利用之前的靈魂難道不是最合理的策略嗎?
2. 如何基于原生HTML進行UI組件開發?
有2個要點：① API參數直接取自HTML; ② 回調直接trigger原生事件;
我們拿上面提過的日期時間選擇器舉例說明下。
日期選擇器，主流實現基本上是這樣的：
new DatePicker($("#date"), {
type: "date",
initDate: ..,
beginDate: ..,
endDate: ..,
onSelected: $.noop
});
API參數，事件的回調全部源自JS參數。
而面向HTML的設計思想下的實現則是：
new DateTime($("[type=date]");
API參數全部取自HTML，JS代碼僅僅就是全局初始化(一次覆蓋所有時間類控件)。其中HTML中的type屬性對應JS中的type API, value屬性值對應initDate值, min/max分別對應beginDate/endDate. 至于onSelected回調，則是通過trigger input框原生的change時間實現。
于是，其他前端小伙伴在開發的時候，就可以按照原生的HTML屬性和事件來開發就可以了，從而實現業務JS和UI組件基于0成本的無縫對接。
三、面向HTML的UI組件開發的好處
- 語義化，可訪問性，SEO等;
- 學習成本低;
- 專注HTML控件本身，而不是組件;
- 可以一次性全局處理;
1. 語義化，可訪問性
畢竟是基于原生HTML來開發的，這一塊必定杠杠的。
2. 更低的學習成本
不需要記住千差萬別的JS API名稱，記住標準的HTML5屬性即可，反過來對一些前端開發同學的HTML學習還起到了幫助作用。
而學習成本低對于跨團隊合作非常有幫助。其他團隊同學樂于使用你的東西，介入快，實現效果好，大家都開心。反之，API千差萬別，每次使用都要去翻文檔，肯定影響合作。
不過，實踐下來，有一點學習成本我沒考慮到，就是轉換思維方式的學習成本。實際上只要面向元素的HTML元素開發就可以了，但是有遇到小伙伴，還是按照老的思維方式，在生成的UI組件元素上做文章。
3. 專注HTML控件本身，而不是組件
舉個例子，日期選擇器，當日期修改了，我們要干嘛干嘛，直接：
$("input").change(function() {});想要修改日期范圍，直接：
$("input").attr({
"min": "2015-12-27",
"max": "2016-12-27"
});UI組件會自動同步。沒有任何組件相關的JS代碼，也沒有什么故弄玄虛，沒有所謂的高屋建瓴，全是很簡單基礎的HTML操作。是不是這樣的開發反而很省心，連小白用戶也能上手?
于是乎，在多團隊聯合協作開發的時候，前端開發的進度并不會受UI組件開發影響，面向HTML，專心自身業務開發就可以了。
于是乎，實現了一個聽上去很了不得的東西：前端分離。
不僅如此，廠子里有很多開發，負責內部項目，會寫JS擅長業務功能實現，但是，UI這塊是個軟肋。OK，此時，我們這里面向HTML開發的UI組件體系就是其救星，對吧，直接引入CSS和JS，簡單全局初始化一下(可能還有一些簡單的微調)，結果，頁面立馬高大上了，是不是很有用!
4. 可以一次性全局處理
傳統實現，每個具體業務的腳本里面要參與UI組件的具體API參數設置。而面向HTML的實現，API落地與具體的業務頁面，于是乎，只要在項目的common.js中全局初始化一下，如下拉Select.init(), 具體的業務JS文件(絕大多數情況下)中就無需再出現UI組件相關的JS代碼。
UI層的JS代碼和業務層JS代碼分離，實現進一步的「前端分離」，去耦合。對于日后的維護、升級等必定大有裨益。
四、總結
本文主講設計思想，至于具體的技術細節，以后有機會會慢慢分享。越是簡單的成品越是需要足夠的積累。
然而，現在的我再重新評估UI組件的實現，還是有一些遺憾的，主要遺憾在于，HTML層→數據層→展現層這三層概念實現的時候并沒有理得很清楚。目前，HTML層和展現層沒有任何問題，但是，數據層，并沒有完整貫穿整個UI組件體系，導致，本UI組件體系不能很好地吸引對JSON數據有著偏執愛好的開發，以及應付潛在的極端需求。
不過，不要擔心，明年，也就是16年，我會對組件設計進一步增強，首先，不考慮IE7瀏覽器，于是可以做的事情就更多了;其次，清晰的數據層作為中間層的代碼重構等。
以上，希望本文的內容能夠對大家有一點啟示。
來源：http://www.zhangxinxu.com/wordpress/?p=5180
作者：張鑫旭