面向設計的半封裝web組件開發

本文完整版地址已經在發表在ISUX團隊官方博客：http://isux.tencent.com/half-package-web-components-for-design.html 歡迎圍觀，歡迎評論交流！

一、傳統web組件的妄想

目前很多Team和團隊都有自己的一套web組件體系，模塊化開發，封裝良好，上手簡單。然後希望該web組件可以應用到接手的各個項目中，節約日後的開發成本。甚至考慮開源。

這其實是很棒的，但是呢，希望一套web組件各個項目通用？在我看來，除非對項目沒有追求，否則不太現實。

但是呢，希望一套web組件各個項目通用？在我看來，除非對項目沒有追求，否則就是妄想。

爲什麼說傳統web組件想一統天下不現實呢？因爲就像秦始皇一統天下一樣，要犧牲很多很多東西。

1. 犧牲代碼量

   web組件要想適用於各個項目，必然要考慮各個項目的各種應用場景，於是，我們勢必要暴露很多很多的API, 否則根本應付不來。拿模態彈框舉例：有的項目可以拖拽，有的沒有關閉按鈕，有的黑色蒙版可以點擊等，於是，我們至少新增類似dragable, colsable, clickable這些API. 就算這樣，還是會遇到一些特殊的需求，例如，彈框位置上下比例2:3. 業界通常的做法是二次封裝，沒錯，二次封裝，就是在原來就很大很重的web組件基礎上，再搗騰一些代碼。

2. 犧牲代碼質量

   有些項目並不需要兼容老的IE瀏覽器，UI工程師那裏有質量更好更簡單的解決方案。但是，抱歉，web組件在那裏，只能委曲求全使用又老又臭的傳統兼容實現。

   場景支持多，代碼多，邏輯多，代碼容易亂，也更容易出bug。

3. 犧牲設計和體驗

   web組件要想多項目使用且封裝良好，勢必要對UI層進行抽象。但是，UI層一旦抽象了，就等於失去了創新的活力，等於死去：

   而現代web, 隨着CSS3, SVG等現代web技術日趨成熟，我們在UI展現層能夠做的事件就非常多，更新變化也更加快。要是這塊的創新被組件限制，而其他競品在組件UI細節上不斷閃現人性化、情感化的創新之處，交互也更加流暢與舒適。勢必會在新的web發展浪潮中被衝到沙灘上。

4. 組件顆粒度把控

   由於項目差異，以及多人合作等原因，組件顆粒度的把控總是沒法恰到好處，拿捏得當。

5. 跨部門合作

   組件大而重，看上去上手簡單，實際上，API這麼多，誰記得住！我們這邊有切實的案例的，某項目質量非常高，無論是UI, 交互和體驗，各方的評價也很好。後來我們要開始一個新的且比較大的項目，就希望把已有項目很多好的東西借鑑過來。設計還是同樣的一批設計師，但是，前端團隊卻換了一撥人。理想的狀態應該是這樣的，新項目的前端團隊，直接使用之前項目這邊的前端UI組件(除了顏色，尺寸什麼的都是一模一樣的)，less的變量文件顏色一改，分分鐘無縫轉移，多棒啊！

   但是，最後的結果是，新的前端團隊放棄了之前項目的前端解決方案，還是使用了自己的簡潔派做法，seajs + jQuery + …

但是，不可否認，web組件對於一般的、尤其視覺這塊要求不高的項目，是很有價值的。只是在應付要求較高的web項目的時候，顯得還有很大的改進空間。下面問題來了：難道我們要爲了一些交互體驗和視覺效果放棄這些web組件嗎？

答案顯而易見，web組件還是需要的。但是，也不能像現在這樣，直接使用。我們需要順應時勢，轉換思維，試試走“面向設計的半封裝web組件”。

二、轉換思維，面向設計

傳統web組件是一般都是由前端開發完成，關注點更多在功能與協作上。雖然也有設計支持，但還是比較弱的。於是，當設計師進行某些微創新的時候，往往就要受制於過於組裝的組件的限制。比方說設計師對dialog彈框進行了一些微創新，比方說下面這樣的(無標題無關閉大背景色塊)：

去問開發可行性，結果，開發來了一句：“哎呀，這個結構我們目前的彈框組件不支持！”我相信這種場景很多同學都遇到過吧~最後，基本上都是設計師妥協，還是使用傳統彈框交互或佈局。所以，坊間纔有“苦逼的設計師”的傳聞。

對於一個重視體驗和設計的企業或團隊而言，這是極爲不合理的。居然下游決定上游，技術的目的本身就是爲設計服務的，結果反過來限制設計的發揮，這豈不是本末倒置！

因此，我們有必要轉換思維，面向設計。也就是說，讓設計師自由地設計，我們做技術的，爲之服務，針對特定項目，去調整我們的web組件，剔除不必要的API, 儘量將UI層內容分離出來，交給設計師和UI工程師，精簡我們的組件，同時保證組件的UI品質。

三、轉換思維，分離與半封裝

面向設計的web組件，可以說是根據當前設計量身定製的web組件。大家都知道，定製這東西，雖然最後的效果好，但是人力成本也高啊！怎麼權衡呢？

兩點：分離和半封裝。

1. 分離

儘可能將傳統組件的API釋放出來，交給HTML以及CSS。同時UI層內容從組件中剝離，方便UI工程師做調整，注意是內部調整，不是傳統的模板API。

2. 半封裝

此半封裝是多個項目平行對比而言的，非UI側的核心功能還是封裝良好的，UI層可變，故稱之爲半封裝。

上面兩點使用圖示表示就是：

於是，我們最終的人力成本和以前其實差不多（核心模塊都是一樣的），傳統組件是二次封裝，半封裝組件是內部定製，實際上都是類似的工作，但是，後者代碼量和UI質量要高很多很多：

這裏，有必要加粗強調下：此“半封裝”是針對不同設計風格的項目而言，對於某一個具體項目，其web組件還是完全封裝的，還是有成熟的API接口的。

四、使用面向設計半封裝組件的前提

1. 重要項目、希望成爲精品的項目 因爲這樣的項目需要面向設計，而不僅僅滿足功能，任由開發任性。
2. 設計和UI工程師要給力 如果設計師和開發一個水平，當我沒說；如果UI工程師的HTML/CSS功力和開發一個水平，當我沒說。因爲，組件會由半封裝會變成“半裝瘋”。

五、傳統組件和半封裝組件形象對比

傳統組件就像是中國的法律，一套法律適用於各個省，所以法律大而全，但是，總是難免有遺漏，比方說男的被男的那個，不算那個；

半封裝組件就像是美國的法律，封裝的部分是憲法，全國通過。可變的適用於各個項目的UI層就像是各個州自己通過的法律，自治與靈活。

前者適用於功能爲主，代碼質量要求一般的項目；後者適用於體驗優先，toper級別項目。

六、面向設計半封裝組件的實踐

拿最近項目的dialog彈框舉例。針對某一個具體項目而言，從設計一致性講，彈框的交互細節都是一致的，這裏也不例外。包括以下特點：

1. 不能拖拽；
2. 點擊背景層不能關閉；
3. 水平居中，上下比例2:3；
4. 彈框出現背景內容不能滾動，彈框過高，彈框自身可以滾動；
5. 彈框支持上下間距不變，中間自適應佈局；
6. 彈框尺寸變化時候的動畫支持，不是duangduangduang直接呈現；

大家應該都用過dialog組件，如果使用你們現在團隊的dialog組件，如何滿足上面的需求？按照我的經驗，會這樣：

1. 調用通用的dialog組件，再項目中新建一個js文件，對dialog二次封裝，適用於這個項目；
2. 設置：dradable: false；
3. 設置：closeable: false；
4. 上下2:3怎麼整？估計沒有這樣的API，不用慌，我們幹掉組件的自己的居中定位，然後我們重置下；或者直接勸設計師放棄這種“沒有意義”的想法；
5. 全局回調API中對頁面滾動進行處理；
6. JS實時計算？
7. JS動畫，好像很麻煩的樣子，最快的辦法還是直接勸設計師放棄這種“沒有意義”的想法；

好，我們就此感受一下，傳統彈框組件都幹了些什麼。首先，大家要知道，這個傳統彈框組件很大，API會很多，例如著名的kissy光Overlay就18個API。然後，我們還在這個如此龐大的組件上再次封裝了一次JS代碼(流量啊燒錢啊)。

如果我們的封裝可以滿足設計需求也是挺好的，最好的結果似乎……讓開發遇到了麻煩，尤其上下2:3這個頭一次遇到的需求，以及高度自適應彈框以及動畫支持。

可謂損了代碼效果還不好，賠了夫人還折兵。

爲什麼會有這樣的悲劇呢？

現代web UI多變，類似的UI需求以後一定會更多。傳統組件面向功能，雖看似完善強大，實際對UI層還是鞭長莫及，UI層一任性，組件就哭了。

下面來看看面向設計的分離半封裝的web組件是如何滿足設計需求的。

1. 手上是個半成品的dialog組件，有一些核心封裝；
2. 任何類似是否可以拖拽，是否有某元素，是否背景點擊可以關閉之類API相關代碼全部幹掉；
3. UI層分離，根據設計需求，重新設計HTML，除了z-index外的樣式控制全部交給CSS；HTML側蒙層和彈框合體，便於內滾動實現以及高度自適應彈框；上下2:3定位實現交給CSS完成，於是，當我們進行動畫的時候，只需要關注彈框內部變化元素的尺寸，彈框就會自動定位（CSS自動實時渲染）；
4. 滾動條控制直接組件回調處理，沒有API控制，因爲，針對本項目本設計而言，沒有任何必要。

設計場景以外的任何東西都扔掉，代碼量估計少了一半(面向設計)；根據設計場景，修改可變UI層的HTML結構，配合強大的CSS，充分發揮UI工程師的在視覺呈現上的造詣(分離)；保留傳統web組件在彈框顯隱以及回調處理上的封裝性(封裝)。

最後的結果是：dialog組件的代碼量身定製，代碼量小，邏輯清晰易維護；同時，UI層面向設計，彈框體驗一級棒；定位等交給CSS, 更高性能。綜合下來，整個組件的品質比傳統組件實現上了好幾層樓。

七、最後的小總結

本文內容屬於“面向設計的半封裝web組件開發”的精簡版，如果對某些論點持懷疑態度，可以去這裏細細瀏覽原版。還有，本文目的是讓大家把web組件的構建的重心放在“面向設計”上，“半封裝”只是兼顧設計和模塊化開發的一種權衡策略，具體項目還是要封裝良好，小白也能速度上手。

至少對於我而言，這種組件開發思想，讓項目的組件品質，無論是UI層還是代碼層，都達到了新的高度。

大家不妨細細體味下，並不是要大家立即放棄傳統web組件構建模式，而是可以開闊思維，轉換思路，試着面向設計來思考、定製web組件，遠離傳統又大又重的組件構建。

轉自：http://www.zhangxinxu.com/wordpress/2015/08/semi-package-web-component-development-for-design/