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

原文來自：http://isux.tencent.com/half-package-web-components-for-design.html

前言

本文內容可謂是對大腦認知的一場洗禮。咱們日常提到組件，就會想到重用，各個項目都能使用。而本文的組件，對於某具體項目而言是組件，可是，對於其餘項目，就是個半封裝的半吊子組件。面向設計、面向項目的web組件開發，就是本文要探討的主旨。

1、人與組件

目前這個階段，咱們所使用的web組件都是人所編寫的，所以，人這個個體在賦予組件生命的時候就扮演了相當重要的角色。人的技能背景，我的喜愛，甚至世界觀均可以從組件中獲得體現。但人無完人，所以要想誕生一款完美的組件，須要上下游不少優秀的同事，把本身最棒的世界融入進去，協做完成，其中下面這4個職位參與度較高：

注意到了沒有，前端開發人員處於web組件開發流程的下游；這其實沒什麼，你們通力協做，組件弄好，項目作好，產品作好，皆大歡喜。然而實際上，因爲大學沒有前端專業，所以負責團隊web組件開發的，大可能是從與組件幾乎不相干的後臺開發轉過來的，或帶有明顯的後臺開發烙印的。也就是說，前端開發不只處於下游，還有1/3的身子在web組件以外。

一個web組件的誕生，理想狀態應該是須要設計、UI工程師、前端開發通力協做完成的。有句話怎麼說來着，理想很豐滿，現實很骨感。

現實是：大多數web組件都是前端開發人員一個或數人，按照業界約定俗成的套路實現的，超前於UI設計，遊離於UI重構。什麼意思呢？比方說一個彈出層組件，有標題、關閉按鈕、主內容區域，底部肯定/關閉按鈕。這套結構是業界約定俗成的，開發人員在寫這些組件的時候，會發揮本身的聰明才智，好好地封裝，好好地設計API, 目的就是能夠不用關心之後設計師設計的彈出層長什麼樣子，由於我預留了類名接口，UI工程師換個皮膚就行了；同時能保證組件的整站複用。也就是項目開始以前，成熟、封裝良好、API豐富的web組件就已存在。

親們，讀到如今，大家是否是以爲沒什麼問題，挺好的啊！？對的，在iPhone出現以前，你們都以爲Nokia挺好的。

從人的角度講，這種看似牛逼的路數最大的問題就是無視了分工，所謂術業有專攻，聞道有前後，開發再逆天，也是存在侷限的，或者說是人性上很難避免的東西。

1. 位置與角色

你們應該都知道，設計師和程序員處於兩個不一樣世界的，所以，當其中一個角色獨自承擔另一個角色工做的時候，天然會存在諸多阻礙，其中很重要的一點就是設計重心。

前端開發寫web組件，實際上也是一種代碼的設計，此時，這些程序員氣質濃郁的前端開發人員設計的重點天然是放在組件功能、通用性、擴展性以及易用性上，畢竟這一塊是本身擅長的，至於UI，會預留API或其餘接口，也能知足常規的設計需求。

若是交互設計師或UI設計師來寫web組件, UI和交互可定製則是其設計的重心，發展得好的話，能夠直接成爲另一種流派，直接和(開發背景前端的)面向功能的web組件流派相抗衡。可是，國內的現狀是，設計師通常不參與直接的代碼建設。

實際上，從職位上劃分，UI開發應該是最適應構建web組件的角色，能兼顧設計之美，重構之美，以及代碼之美。只惋惜因爲門檻低，水平參差不齊，尤爲JS方面的駕馭能力有限，因而，最後的結果是，組件的建設都落在了工程氣息濃重的開發身上。

能夠看到，雖然不合理，可是情非得已。有人可能要叫了：「囉哩吧嗦，狗皮膏藥塗到如今，到底哪裏不合理，你到是說啊！」

OK, 稍安勿躁。因爲組件這東西只能開發實現，致使在組件的設計以及使用上，前端開發有了很是大的話語權，下游決定了上游，設計師以及CSSer在組件眼中就是個擺設。比方說設計師對dialog彈框進行了某些微創新，比方說下面這樣的(無標題無關閉大背景色塊)：

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

苦逼的設計師這樣苦逼地工做了不少年，還好，你們就這麼過來了。然而，事物是不斷髮展的，技術是不斷進步的，隨着CSS3, SVG等現代web技術日趨成熟，咱們在UI展示層可以作的事件就很是多，更新變化也更加快。在這種大環境背景下，還讓開發來決定設計，顯然這對產品是不負責任的。其餘競品在組件UI細節上不斷閃現人性化、情感化的創新之處，交互也更加流暢與溫馨；而你還抱着「咱們這是成熟的彈框組件，不能隨便改」的想法固步自封，使用"duang duang duang"生硬，機械，呆板的彈框組件，註定在現代web浪潮中被衝到沙灘上。

對於頁面工程師，切圖仔而言，其實也挺苦逼的。在部門沒啥地位的頁面仔們，苦學了一種新的佈局，比傳統實現少嵌套2層標籤，且知足各類場景需求，好棒！結果交接的開發來了句「咱們的選項卡組件不支持你這種結構，你須要調整下」。

具體項目的具體組件原本就應該是你們通力協做完成的，如今就因「組件是我寫的，我就是發言人」的心態限制設計、重構的創造力。這就是不合理之處。

2. 揚長避短

組件的做用是什麼呢？就是「偷懶」，來個新頁面，「啪」一套；來個新項目，也是「啪」一套。功能棒棒噠，任務完成，老婆不再用擔憂我加班晚歸啦！

偷什麼懶呢？主要是偷本身不擅長那塊的懶。這是人之常情。設計師不懂代碼，他但願的組件是，直接可視化操做就OK的；頁面製做人員，他但願的組件是JS功能那塊它不須要操心；前端開發們，則但願組件HTML佈局那塊不須要關心。

好了，如今組件都是開發背景的前端寫的，因此呢，不少HTML佈局啊，樣式表現啊，都集成在了web組件中，一些動態的表現就使用洋洋灑灑的API控制。因而，開發使用的時候，只要按照特定的套路，本身不須要去寫頁面之類的，組件就棒棒噠了！

這樣的例子不少的，比方說知名開源項目kissy中的選項卡組件，根據個人觀察，其選項卡要麼是要經過JS腳本動態建立，任何特異化的需求都是經過豐富的API接口或者回調實現的。總之，組件的使用只須要玩弄JS, 不須要把玩HTML; 要麼就是套用固定的HTML結構以及className值。這比較符合JS造詣很深的前端開發的偷懶模式。

等等，篇幅緣由，就不一一舉例。

這並無什麼對錯之分。有的企業就是功能爲王，業務導向；有的企業就是產品爲王，體驗優先。不一樣的企業文化，不一樣的產品要求，不一樣的團隊規模與技術能力，決定了web組件的表現形態、使用方式等。只要符合企業的生產與成長鬚要，都是很棒的web組件。所以，相似kissy這樣的模塊集合，是否適用於單兵做戰的中小企業以及注重用戶體驗的創業團隊，就須要執行者好好斟酌斟酌了！說不定，jQuery UI可能更合適一點。

至少對於我而言，毫不會去使用對HTML作過多限制的web組件的(例如要求節點必須如何如何...)：

KISSY 1.4 srcNode 初始化組件時必需要求內容節點必須包含類名 ks-overlay-content (這裏 ks- 爲 prefixCls)...

「揚長避短」本來是個褒義詞，顯然，我放在這裏講，是要說其很差的。有句話講的好，叫作術業有專攻。前端開發都會HTML/CSS, 畢竟相比程序開發，門檻很低，在相關領域也浸染了些年月，構建web組件的時候，感受HTML/CSS方面的應用也是比較順手的，功能也都能跑起來。可是，在HTML/CSS方面造詣很深的開發看來，前端開發web組件的HTML結構等設計不敢恭維。舉個真實的例子：

要實現一個相對文本框定位的Autocomplete組件(相比絕對定位, resize時候無需JS重定位)，前端開發是這麼實現的，在<input>文本框外面wrap包裹了一層<div>標籤，設置position爲relative, 而後Autocomplete主列表容器就在這個包裹<div>裏面，絕對定位於該<div>, left/top值與文本框尺寸關聯。

最後的實現，效果是有的，兼容性也是能夠的，在前端開發看來應該是OK的，自我滿意的。可是，在我看來是至關糟糕的！

這外面包裹的一層<div>標籤徹底是多餘的，咱們無需包括標籤就能實現咱們想要的相對文本框定位效果，並且兼容IE6+. 目前的實現，這個包裹的<div>看上去貌似起到了輔助劑的做用，實際上留下了超級隱患，讓組件生命力(適用性)立馬下降50%。

小隱患是，可能相鄰父子選擇器會失效，比方說.parent > input選擇器，會由於莫名其妙爸爸變爺爺致使文本框樣式失效，這個問題嘛，改改CSS就能夠了；以及多了一個relative, 元素的z-index層級管理又更復雜了一步，維護成本增長了！

超級大隱患是，Autocomplete組件下拉框高度超出容器高度是很常見的，可是，因爲你外層有了一個position:relative的父級，只要外面任意一個容器有overflow:hidden，你的Autocomplete下拉就會被攔腰斬斷，部份內容不可見；若是是overflow:auto/scroll，則會出現討厭的滾動條。這個組件基本上就廢了！可是，若是沒有外面這層討厭的position:relative父級，overflow:hidden就幹不掉下拉列表，Autocomplete組件就能長青不老，適用性提高了整整一個量級。

上面截圖，仔細看會發現有個*-placeholder的<label>元素，先不說這個label元素沒有for屬性，要知道，企業產品近8成用戶的瀏覽器都支持原生placeholder(包括顏色等自定義)，對於這部分瀏覽器，我實在想不出任何須要自定義實現placeholder效果的理由。最大的可能性是前端開發童鞋不知道目前凡是支持placeholder屬性的瀏覽器均可以CSS自定義吧。也就是前端開發自己的技術深度以及視野的侷限。

咱們對上面的絮叨總結下，就是想表達，人的侷限性帶來了web組件的侷限性，惟有相互協做，告別單職挑大樑，才能讓web組件有所突破。可是，目前這個階段，這現實嗎？優秀的前端如此匱乏，尤爲可以上下游承接的，想尋求突破，咱們是否是能夠從別的地方入手？

2、組件的抽象與封裝

咱們在寫web組件的時候，咱們老是會盡量地去抽象功能，封裝API。 因而，當咱們使用這些組件的時候，咱們只須要針對一些經常使用API去作設置，就能知足咱們平常的功能。

在很長一段時間裏，我一直都是這麼作的，業界幾乎全部開源的web組件，包括團隊內的web組件都是這樣的設計思路。

然而，隨着時間推移，在各類類型的項目中浸泡，我發現，儘量地去經過JS的手段封裝組件彷佛不是將來的趨勢，反而可能會成爲一種制約。

1. 現代web技術發展

CSS3/HTML5等現代web技術不斷髮展，以及IE6瀏覽器的淘汰。瀏覽器自身可以完成的事情要比之前多不少不少。舉個極端的例子(都是廠內現有的真實案例)，模擬單複選框的web組件，若是按照傳統的組件開發模式，API這塊(events回調API缺省)可能就會是下面這樣子：

從代碼的角度講，仍是很美的，對吧；功能上也是能夠的，各種需求也能知足；API的抽象與封裝也是沒有不足。只是，恕我愚鈍，這洋洋灑灑600+行的JS代碼的價值在哪裏？在IE9+瀏覽器下，單複選框的自定義效果是不須要一丁點一絲絲JS代碼的，對於IE7-IE8瀏覽器，咱們只須要關心input自己，全局委託click, 讓單複選框input的類名和checked狀態保持一致就能夠了，其餘的交給CSS選擇器完成就行了。所有的代碼量跟上面截圖API參數代碼量基本上同樣，並且對設計師和頁面重構人員更加友好。

工程化的思惟方式，高度的邏輯思惟與抽象能力，以及造物者的美妙感受，彷佛讓開發熱衷於設計與封裝API, 熟不知，當新技術出現，或者發現有其餘更簡單的實現的時候。那些所謂的封裝是顯得那麼的笨重與雞肋。

「好了，你別說了，我改還不行嗎？」組件這東西，由小變大很簡單，能夠向前兼容；你想從大變小，我只能呵呵。仍是等下一個全新的版本，或者其餘徹底不相干的項目了，兄弟！

2. 變幻莫測的UI層

現代web技術的發展，讓咱們在UI表現上能夠有更多的選擇。這對web組件UI這塊的抽象與封裝帶來了很大的挑戰，來看看一些同行的言論吧：

若是有組件自信對UI層進行了完美地抽象與封裝，這代表，這個組件已經對UI層的表現有了很大的限制。這是毋庸置疑的，有些事物自己就是對立的矛盾體，工程化就是要講求一致性，可是，個性化顯然就是須要不一致，而UI表現就是一件很個性化的事情。So, ...

當前的web組件面對新項目新的UI表現需求，採用的作法要麼就是new一個新的封裝進行二次封裝，要麼多些寫代碼作冗餘處理。恩，都不是什麼好作法，不過又沒有辦法。

3. 跨部門的合做

最新，咱們完成了一個項目。這個項目質量很是高，不管是UI, 交互和體驗，各方的評價也很好。後來咱們要開始一個新的且比較大的項目，就但願把已有項目不少好的東西借鑑過來。設計仍是一樣的一批設計師，可是，前端團隊卻換了一撥人。理想的狀態應該是這樣的，新項目的前端團隊，直接使用以前項目這邊的前端UI組件(除了顏色，尺寸什麼的都是如出一轍的)，less的變量文件顏色一改，分分鐘無縫轉移，多棒啊！

可是，最後的結果是，新的前端團隊放棄了以前項目的前端解決方案，仍是使用了本身的簡潔派作法，seajs + jQuery + ...

各位觀衆可能會疑問了，咦，爲啥不使用現成的東西啊？主要緣由就是上手成本和學習成本，企業這邊的前端組件體系能夠和kissy一拼了，面向對象、模塊化、按需加載，API封裝也是盡善盡美，走Grunt.js玩nodejs, 先後端分離，走得還挺超前的。可是，本身團隊內部新人有人帶，有人教，能夠慢慢上手。可是，你這一套東西交給其餘團隊，考慮到其量級以及複雜度，以及項目的緊急程度；一看到你那洋洋灑灑N多的API參數，着實讓人望而生畏。以及還有不可忽略的代碼風格、模式等差別。

爲何會有那麼多API？

這個問題頗有意思：「爲何會有那麼多API？」 這個問題可謂是問到點子上了。本來組件誕生的時候，API是沒有這麼多的，後來，現有的API不能知足某些UI層或交互層的使用場景，因而，前端開發就抽象一下，新增一個API, 知足這個需求。可是呢，這項目啊是一個接一個，需求呢，也是變幻無窮。沒過多久，又來了個需求，開發力排衆議，仍是沒能擋掉，結果，又在組件裏新增一個API。 長此以往，就有了如今看到了不少API參數，此時，這個web組件就能夠稱爲「成熟的web組件」，對外宣傳「適合多種應用場景」。這其實頗有意思，所謂的適應性竟然是經過增長各類API，增長組件代碼量實現的，而後還自我得意一番。我開始有些明白爲啥小小的單選框模擬組件竟然須要600多行的JS代碼了。

歸根結底，仍是「儘量對組件API進行抽象和封裝」這樣組件編寫意識致使的，這種想法和意識實際上已經不符合發展的趨勢了。

咱們看來有必要轉換思惟。

 

3、轉換思惟，分離與半封裝

你們都知道YUI已經中止維護有段時間，至於緣由，不知道你們有沒有好好體味下(參見下圖言論)：

正如我所言，爲了知足UI需求，講求封裝的設計理念，必然會致使web組件愈來愈大，愈來愈臃腫；同時，前端開發這個角色因爲關注點和職位跨度緣由，對於UI層的處理能力和其對JS語言自己的處理能力仍是有不小差距的。

所以，考慮到將來發展，咱們必須作出適當的改變。我我的以爲能夠從這兩方面尋求改變：分離和半封裝。

1. 分離

實際上，目前的UI組件也是有分離的，不少樣式均可以經過類名控制。然而，這些分離都是逼不得已的，比方說Autocomplete的列表樣式，你總不可能每一個列表都內聯一段樣式相同的style設置吧。可是，若是條件容許，樣式控制都是儘量在JS中完成的，例如Autocomplete的列表容器的尺寸、定位、層級等等；甚至有些組件直接內嵌完整的CSS代碼。

這樣的設計是奔着足夠封裝，調用方便去的。可是對UI的友好程度，恐怕就不是設計者的關注點了。

顯然，這裏要講的「分離」要比傳統的「不得已分離」要更進一步。包括兩方面：

①. 樣式控制從JS分離

即只要是靜態樣式控制，所有交給外部的CSS來完成。甚至包括組件的狀態控制(尤爲是隻要支持IE9+的項目)，例如顯示，隱藏等等。

拿經典的彈框組件舉例。至於absolute定位，仍是fixed定位，背景色是黑色仍是其餘，透明度多少，彈框是否居中定位等等，組件都無論(目前這類全都JS API控制)，組件要關注的是功能層面的東西。千萬不要本身爲是，使用JS計算讓彈框居中顯示(外帶resize重計算)。UI需求不是你可控的，比方說咱們這邊幾個項目的彈框的需求是上下2:3滾動跟隨顯示，CSS徹底能夠實現此效果，CSS纔是最好的UI樣式API。

說到這裏，忍不住爆料下，因爲各類錯綜複雜的緣由，項目的彈框組件Overlay的透明度和顏色API目前是個醬油，自定義沒效果。因而，最後仍是使用CSS的!important重置了JS的style控制。若是當初全都交給CSS, 什麼事都沒有，還省了一大波JS代碼，呵呵呵！

②. 參數來源從JS分離

舉個最簡單的例子，文本框/文本域的placeholder佔位符效果組件，其佔位符內容經過JS的{ placeholder: '' }參數賦值嗎？很顯然，要優先使用HTML元素上對應的屬性值。這實際上是很基本的常識，然而，不少組件只有JS API這一個入口。

或者tips組件的提示內容源自元素的title屬性等。

即符合語義，頁面工程師還可控。一舉多得。

以上的分離，省JS代碼是小，更大的意義在於釋放了UI設計師以及UI工程師的潛力，使上下游全部的成員角色都參與到web組件的建設中來，只要這個設計師的設計能力＞開發，頁面重構人員的重構能力＞開發，這個組件的品質，絕對就會比前端開發一我的完成的質量要高。並且，對於其餘不一樣UI風格的項目具備更強的適應性。

2. 半封裝

一提到web組件，咱們很天然跟封裝聯繫在一塊兒。對啊，你不封裝怎麼叫作組件呢？如今，咱們有必要轉換思惟了，要想知足日益高漲的UI層需求，同時組件不會日趨臃腫，咱們就須要對組件進行半封裝。

那問題來了，什麼是「半封裝」呢？

所謂「半封裝」是指咱們只封裝語言層面以及功能層面的東西；對於UI層，雖然也是JS, 但咱們按照CSS的思惟處理，以知足當前項目UI需求爲主，不講求封裝以及API設計，保持隨時的激活態，不管是UI工程師或者前端開發均可以根據具體項目具體需求調整之。

須要注意的是，此「半封裝」是針對不一樣設計風格的項目而言，對於某一個具體項目，其web組件仍是徹底封裝的，仍是有成熟的API接口的，小白開發也是能夠直接使用的，只是不能直接應用到其餘項目！

分離，和半封裝使用示意圖表示就是：

對應的職位參與以下：

從上圖能夠看出，我在第一章節大肆分析的當前web組件分工不合理性(見下圖gif)獲得了很好地解決。web組件樣式控制CSS化，以及非封裝的HTML結構、類名等大大提升了偏設計的前端對組件建設的參與度，對組件設計品質的提高，很是有幫助。

關於web組件的半封裝性

對於開發思想濃郁的程序員，可能有些沒法接受這所謂的「半封裝」思想。我cow, 每來一個項目，都要對組件進行一番修整，人力成本怎麼算？若是支援10個項目，就有10個子組件，往後維護怎麼辦？

關於人力成本：
傳統的web組件是由前端開發在原組件基礎上二次封裝成項目須要的web組件，這個成本，跟直接動組件代碼中的小部分UI層內容，實際上沒什麼區別的，這個下一章節再次提到；

關於維護成本：
首先對於每個具體項目而言，組件都是通用的，而半封裝，只是對其餘項目而言是半封裝，對於具體項目依然是個全封裝的web組件，跟傳統web組件維護成本是如出一轍的；

其次，半封裝的web組件，非封裝的部分是多變的UI層，總體結構依然是面向對象開發，其餘部分依然使模塊化加載，所以，看上去10個子組件，實際上僅僅是10個跟實際項目緊密契合的UI佈局相關的子組件。要知道，UI層原本就應該具備特異性，獨立開來反而下降了樣式調整帶來衝突的可能性。

最後，對於不一樣項目而言，組件自己就應該是獨立不耦合、相互無關聯的。比方說jQuery, 10個項目都使用jQuery, 有個項目須要使用jQuery某新特性，因而升級都愛了2.0, 其餘項目也要更着升級嗎？顯然是不推薦的，對吧，新版本的瀏覽器兼容性可能不同，一些老的API可能刪除了。jQuery何況如此，咱們實際開發時候，10個項目實際上就是10個組件體系，別看貌似代碼都是同樣的，維護起來仍是要獨立維護。

所以，綜上所述，根本就不存在增長往後的維護成本。

半封裝web組件惟一的問題在於，對小白從業人員不友好。不少新人就是大天然的代碼搬運工，就是但願組件足夠傻瓜化，最好直接引入一個JS文件，本身想要的功能就出現了。這就是爲什麼咱們平時在互聯網上看到的開源的web組件都是封裝很良好的緣由，你使用麻煩，哪一個小白會使用！同時，由於須要考慮各類應用場景，API不少，組件很重，爲了宣傳，只能美名曰強大、適用於各類場景。正如無招勝有招，沒有使用場景纔是最能適用於各類場景。

咱們在企業打工吃飯，首先考慮的應該是組件自己的質量、產品和項目的質量，至於開源什麼的，是否是想太遠了。

咱們有專業且可愛的同事們，爲什麼要把合做的同事當小白，而不是不發揮各自的特長，一塊兒把產品弄得棒棒噠！？

舉例補刀

就在我寫到這個位置的時候，高級視覺設計師J向我諮詢日期時間選擇組件的時候，出現了這麼一句話：

網上可以找到的日期時間選擇web組件都是封裝良好的web組件，對於對設計沒要求的小白用戶或者一些小廠很友好，可是，對於對設計很重視的使用場景，所謂的「徹底封裝」反而成爲了一種制約，且不說組件的class類名風格是否符合團隊規範。

其實，咱們但願模塊化或者組件化的東西是日期篩選或者排列的算法。對於UI層，你大肆集成，一了百了。最後的結果呢？被設計師嫌棄了！其實呢，裏面的HTML構建也被HTML工程師嫌棄了！後來，設計師委曲求全接受了一款時間選擇器組件，結果還不支持IE7瀏覽器，真是造化弄人啊！

正在閱讀的你，遇到這種狀況你會怎麼辦？試想下，若是咱們有一個半封裝的web組件，UI層內容和模塊層內容清晰且獨立，此時，UI工程師就能夠專心搗鼓UI層內容，能夠知足設計師任何挑剔的需求，豈不美哉？！

 

4、面向設計高級定製的產品組件

怎樣的產品才高端，有檔次，脫穎而出？

咱們能夠拿衣服爲樣板，回答上面這個問題。

很顯然，私人定製的衣服要比流水線上生產的衣服，要更有檔次，產品品質要更高。

徹底封裝的web組件，就比如流水線上的衣服，講求工業化，效率以及成本。可是，這樣的web組件作出來的產品的檔次和質量，未免有粗糙之感。而本文所反覆推崇的半封裝的web組件，很是重視量體裁衣的設計、量身定製的交互，使得咱們的web站點猶如私人訂製的高級禮服。在芸芸產品中脫穎而出，贏得口碑。

須要明白的是，私人訂製並意味着徹底放棄工業化、模板化的東西。就算你讓玉蘭爲你設計高檔禮服，禮服的製做過程當中，仍是會用到線稿、樣板等等。只是並不是徹底的流水化。面向設計的半封裝的web組件也是這麼回事，咱們仍是須要面向對象、須要模塊化加載、通用的事件處理等等，只是這些成爲了背後的一部分而不是所有。

下面咱們一塊兒來看一個頗有意思的問題，初期開發成本問題。

面對設計的要求，咱們之前的作法是這樣的，web組件不動，針對具體項目，common.js中來個二次封裝；而如今的作法是採用私人定製的方法，在原web組件根據設計需求，搗鼓UI相關內容。差別見下示意圖：

都是須要爲了知足UI的需求作一些工做的，因此前期工做成本並很差評估。可是，能夠確定的是，JS的代碼量降低了不少，且對於設計對於UI的定製性更強了，若是團隊有不少厲害的設計師，這個web組件的品質就牛大了。

個性化設計與工業化生產的矛盾

每一個企業應該都有本身重視的產品，並且都但願這個產品各方面品質都高人一等，對，是各方面品質，這樣纔有競爭力，咱們騰訊更是看重產品品質。

咱們有不少頂尖的產品經理和交互/視覺設計師，設計的web控件既美觀又大氣、並且還親近用戶，細節上不少微創新，高品質的產品有個產出的前提，但也只限於前提，最後的呈現仍是須要開發來實現的。

可見，開發同窗在產品品質的把握上是多麼的重要。

每一個IT企業裏面都有一個或一羣開發，他們但願本身的代碼能夠改變世界，同時吸引軟萌妹子；他們但願經過代碼生產工具以及相似可複用的東西，解放生產力，提升效率；他們但願本身的代碼功能棒棒無bug, 性能卓越無匹敵。

正如以前講過的，既是優勢也是侷限。重複利用的天性刻在了骨子裏，雖然中心明白設計很重要，可是，對於設計效果的實現，總會讓設計師苦笑不得，爲什麼？

由於這自己就是矛盾的，優秀的開發講求代碼複用、性能，然而個性化的設計就是要不同凡響，避免複用。因此，各位開發同窗，若是你的團隊設計很優秀(若是設計跟你一個水平，忽略這句話), 爲了產品的高品質產出，咱們必須有強烈的面向設計的開發思想，首先第一點就是心理上要可以接受，各個項目之間基本上無法重用的web組件；其次，行動上，願意花一些額外的功夫和心思，雕琢設計的細節實現。

等最終高品質的產品出來了，心裏會很充實會自豪，你會發現本身有了長足的成長，設計師MM彷佛對你更友善，跟你說的話也比之前多了。

舉例與補刀

就在上個月剛剛完成了一個取色器的定製，這裏來分享下哪些是須要高級定製的，哪些是按照模塊化使用的？首先下面這個是設計圖：

首先，這個取色器特異性很是強，網上絕對找不出第二個取色器組件長這個樣子。因此，崇尚天然搬運工的，能夠洗洗先睡了。雖然網上有不少取色器組件，我看過他們的實現，不得不說，真不怎麼樣(直接搞一張漸變圖片是要鬧怎樣)。因此，爲了還原設計品質和保證組件代碼質量，反而是高級定製來得簡單快捷。

首先，咱們要分離UI內容和組件模塊內容。模塊內容包括：Dropdown組件(含邊界判斷)，顏色轉換模塊(HSL, RGB, HEX格式間顏色轉換)；剩下就是UI層內容，這是須要私人定製的。沒錯，這個組件的定製工做量比通常的組件要大不少。從代碼量來看，要五五開。

再次強調下，你們必定要摒棄「web組件完成後儘可能不要動裏面代碼」這樣過期的想法，爲了知足設計，額外的成本付出仍是須要的，只是之前只在外面小打小鬧，如今是內部調整。

至於如何具體分工，因團隊結構個每一個人擅長的領域不一樣而不一樣。

好，這裏，有必要加粗說一下：恰如禮服定製須要技術嫺熟的製衣工人同樣，web組件若是想走面向設計的高級定製策略，團隊裏必定要有相似的技術嫺熟的前端人員，不然會有至關高昂不划算的定製成本。

5、實踐出真知

近2個月以後……

前面提到過設計師jerry對日期時間選擇組件的諮詢，後來，莫名飛來一些蝴蝶，這個日期時間選擇組件就我來實現了，基於面向設計的半封裝理念，我是怎麼實現的呢？

1. API分離 - 迴歸UI組件的本源 - HTML
   你們都知道，HTML5裏面，自己就是有相似date, datetime類型的input控件的，如Chrome瀏覽器下會自動調用本身的時間選擇控件：所謂UI組件，無非就是實現知足產品氣質的統一兼容的瀏覽器的那套東西。道家講求追本溯源，從這個哲學層面講，使用瀏覽器以及HTML5規範那套交互體驗，必定是最佳實踐。傳統的洋洋灑灑的JS和五花八門的API都是逆時代而行，註定要成爲歷史的。所以，我這裏實現的日期時間選擇組件基於原生的規範的HTML5 input元素實現，沒錯，只能是input元素。具體包括：

    

   <input type="date">
   <input type="year">
   <input type="month">
   <input type="hour">
   <input type="time">
   <input type="minute">
   <input type="date-range">

   每種type列表對應一種時間選擇面板。例如，選年的，和選月的（終效果截圖）：

   不只僅如此，可選時間範圍，甚至包括時間選擇的跨度均是經過HTML原生屬性設置完成。包括：min, max, step等。

   <input type="date" min="2015-07-03" max="2015-07-28">
   <input type="hour" value="09:20" min="8" max="20" step="2">

   min對應於傳統日期組件的startDate API, max對應於endDate, value對應於initDate。

   而這裏，咱們將類別交給type, 範圍交給min/max, 從JS分離出來，交給了HTML. 即增長了組件的可讀性和可訪問性，同時，給咱們的組件瘦身，能夠專一於呈現自己。

   最終，咱們的組件API就很是的簡練，只須要一個onShow()/onHide()回調，使用也更加規範（由於遵循的HTML5規範），記憶與學習成本也更低。最最厲害之處在於，咱們只要在common.js全局實例化一下，例如：

   $('input').each(function() {
       var type = $(this).attr('type');
       if (/^date|year|month|time|hour|minute|date\-range$/.test(type)) {
           new DateTime($(this));
       }
   });

   其餘全部子頁面，你都不須要額外的JS, 設置額外的API。 只要按照HTML5規範，寫好HTML內容，日期時間選擇功能就槓槓地呈如今那裏。

   工做不要過輕鬆哦！

   什麼？選擇日期的回調？

   用戶只要關心input元素自己就行了，就跟使用原生的input元素同樣，給其綁定change事件，當文本框中日期變化的時候，change事件就會自動觸發。能夠說，就算沒有這個UI組件，咱們的頁面功能也是能夠正常使用，這就是API分離給HTML在可訪問性上的質的提高。

2. 面向UI設計的高級定製
   UI層的東西變化性很是強，你不可能說是寫了個組件，適用於全部團隊，全部場景，那你的組件該有多大，多少邏輯判斷哈！對於某一個項目而言，是不須要的，咱們須要穩固的核心，以及在這個基礎上，面向UI的高級定製。日期時間選擇比較難實現的一個面板就是日期範圍選擇，相似這樣：其實呢，要實現有此功能而且功能通用的組件，並不難，咱們從網上找一下，也是能夠找到的。可是呢，若是你看了設計師對選中細節的處理，你去找個能夠知足如此UI設計的組件看看，就很難了！那些細節呢？包括：

    

   1. 獨立選中真空；
      
   2. 非首尾選中實色；
      
   3. 首尾選中半直角半圓角；
      
   4. 首尾選中處於邊緣且折行則頂到邊緣且半開放；
      
   5. 首尾選中處於邊緣不折行則不頂到邊緣；
      
   6. 正常區域方方正正，選中頂到邊緣。
      
   7. ...

   咋整？顯然，面對如此UI，咱們須要對組件內部實現進行簡單的定製，主要定製內容包括：

   1. 一般態類名
   2. 選中態類名
   3. 選中起始類名
   4. 選中結束類名
   5. 月初類名
   6. 月末類名
   7. 星期幾對應列類名
   因而，極端狀況，這麼多類名會同時出現：

   若是咱們是一個普通的日期選擇器，只要兩個類名就能夠了：.ui_date_item和.selected。可是，當咱們面對的UI組件的樣式很是精緻的時候，咱們就必須根據設計量量身定製一些類名，輔助實現咱們的表現層效果。這樣的成本是必須也是必要的。

   提問？咱們還須要對國家法定節假日（包括週六週日）作處理嗎？

   從組件自己強大角度講，支持天然顯得更牛，但實際上這只是開發人員本身的感受，現代組件講求輕便靈活，若是項目沒有這樣的需求，咱們就沒有必要作相似的處理；若是後期提出了需求，咱們再處理之。

   這種思惟方式有別於傳統的——「我須要考慮好各類使用場景，弄一個功能豐富強大的組件」；而是「UI層須要什麼，我代碼就作什麼，儘可能減小API，只考慮經常使用場景，生僻場景置之。」

3. 模塊化組件部分
   組件體系通用的定位模塊。時間選擇器內部每種類別的面板也是獨立模塊，分獨立調用也能夠從其餘面板切換調用。
   

   6、最後的大總結

   1. 爲了最大化組件的品質，組件的實現要講求分工；
   2. 要想分工，須要將組件UI層東西從JS剝離出來，發揮CSS/HTML工程師的在UI處理上造詣；
   3. 想要剝離，就要求組件半封裝，避開大而全的API；
   4. 所謂半封裝是功能封裝，UI不封裝；但對於某一具體項目，組件仍是徹底封裝的；
   5. 避開API的方法包括交給原生的HTML屬性API, 以及根據項目UI場景設計API，告別無心義的生僻場景API的使用。
   6. 發揮CSS的潛力，儘可能避免使用JS作一些本身爲是的功能；
   7. 面向設計的組件構建思想只適用於戰略級項目、或但願成爲精品的項目，以及須要配備優秀設計和UI開發。不然傳統的大而全的組件反而更適用。
   8. UI組件的本質是HTML和CSS, JS只是輔助，千萬不要亂了主次。

   最後，咱們獲得的就是一款UI設計精良，同時代碼輕便簡潔，量身定製的高級web組件，配合模塊化的管理，整個項目的品質就能夠有質的提高。

   OK, 以上就是本身對web組件的一些思考和感悟，可能講得有些囉嗦（概要版點這裏），但願不會影響中心思想的傳達。另外，你們讀完以後有什麼想法，或者自己就對web組件有一些思考，都歡迎留言討論。

   最後，感謝閱讀！