讀過，了解過很多的前端控件庫/組件庫，嘗試過，體驗過多個失敗的，不算失敗的組件庫之后，總結下來，覺得要構建一個完整的組件庫，需要考慮以下幾個方面的問題：
1.基礎庫：
注意是庫，不是框架，基礎庫通常提供底層方法，它必須能夠屏蔽瀏覽器/終端的API差異。也許大家腦子里面會彈出一堆前端熱門的一些庫。在此不討論哪個庫哪個庫怎么樣，一個基礎庫必須提供的功能：
- 基本類型的常見擴展：原生的javascript對象API往往在現實中不夠用，比如常見的Array.indexOf/remove/each，Date.parse/format，不管是怎么封裝都需要這類方法
- DOM操作常見方法：DOM節點增刪改查，CSS selector，DOMReady，contains，add/remove/toggleClass，屏蔽瀏覽器之間的操作差異。不多說，人人都熟。
- 一套瀏覽器檢測機制：以前大家都傾向于做瀏覽器類型和版本的檢測，現在傾向于做瀏覽器的特性檢測，這樣更有實際用處。
- Ajax的封裝，對于組件庫來講可無。畢竟組件庫本身的實現不太會用得上Ajax。
2.事件機制：
addEventListener/removeEventListener/dispatchEvent 是常見的封裝方式，不應該只是DOM事件，而是任何對象都可以做一個事件機制。
對于DOM事件的封裝需要屏蔽IE/標準Event的差異提供為用戶使用，事件代理非常重要，不可小視。
- 事件機制都無一例外的是基于第三方觀察者或者叫做沙箱(Sandbox)實現。
- 事件機制更深的功能是提供一個模塊的通信機制。
- 對于組件庫，組件實例之間的通信更加重要，組件實例之間最好不要存在相互引用的關系，互相不能感知對方的存在，有了事件機制，可以通過第三方有效的通知組件實例，減少組件實例間的耦合。
3.模板機制：
實際上寫組件的時候，拼裝html是一件很復雜的事情，模塊能夠從數據模型，對于組件庫來講通常是配置信息選項。將這些選項拼裝成html字符串。但是大家普遍的一個誤區是在追求語法的簡便的和性能。我倒覺得模板要做的事情遠不止如此。功能強大的模板不僅僅只完成字符串的拼接，而是要簡化整個DOM操作，從數據模型到DOM的雙向綁定，Model更新了DOM也隨之更新。甚至要解決動態DOM事件綁定的問題。
4.面向對象的機制
放在組件庫這個角度去談面向對象的時候，他是一個架構設計中的一個重要的一環。
面向對象的機制能有效的提升代碼的可復用性和擴展性，javascript靈活的語法諸如prototype/closure的方式，能構建出一個強大的類庫。
可以使用繼承機制擴展已有的組件。也可以用引用的方式裝飾(Facade)現有組件，個人更傾向于使用裝飾。因為繼承總會不可避免的直接或者間接去訪問父類的一些私有屬性方法。
這個機制其實決定了一個組件的代碼模型，通常需要解決的問題有：
- 該組件繼承自哪些組件或者基礎類，或者依賴于那些類？
- 組件實例的管理方式，因為每個組件實例都需要在一個容器中統一存放，理想的的存放模型應該是樹形的，在內存中存在類似DOM樹一樣的組件對象樹，是否可以通過類名找到相關實例，根據ID獲取實例，獲取子實例，父實例，父/子實例之間的通信父實例的resize是否能通知容器內的實例resize。
- 插件機制：作為一個非常重要的擴展機制，插件能有效的解決組件間的復用部分，通常這部分會叫做行為(behavior)，對于組件不能提供的甚至是個性化的功能，有沒有提供有效的，足夠多的擴展點。
- 提供怎樣的實例化方式？ new XXX() ?? 還是類似DOM的操作方式appendInstance??甚至有類似jq這種鏈式。我更覺得應該使用appendInstance的方式，這樣能更加有效的體現組件示例間的父/子關系。就像DOM操作一樣，最終組件實例也是樹形結構，如果我們直接new XXX() 這種方式，其實相當于聲明了一個游離態的 DOM節點。實際我寫代碼的時候發現要管理這些組件實例也是比較麻煩的地方，試想一個頁面如果有多個組件實例，需要聲明多少個實例變量，或者申明多少個對象去存放這些實例。
- 組件提供的API，一個組件對外暴露的API會包括初始構造方法，公共方法(method)，事件(event)，對于event，提供怎樣的eventData也非常重要。
5.模塊化機制
如今模塊化的思想已經深入人心，模塊化帶來了很好的團隊多人完成一項大的任務的可能性，符合高內聚低耦合的思想。到了如今這個時代，萬物皆模塊。
組件庫通常是一個龐大的工程，單靠個人英雄主義很難做的完整全面。
詳細的來講，模塊化機制涉及：
- 模塊本身的定義，注冊，直接影響一個組件的代碼模型，一個組件是一個模塊。
- 模塊的依賴申明以及追朔機制：就像前面提到的，依賴于那些類，css文件，資源，數據。不僅僅需要聲明，還應該可追朔，依賴的父類，也能找到父類本身所依賴的資源，這樣為按需部署打包，在線調試提供居多方便。
- 加載機制：因為在開發階段要么放一個整個組件庫代碼，要么是通過一個加載器按需加載，到了線上希望只部署引用到了模塊組件，這樣可以減少實際部署的文件大小。加載機制會涉及到瀏覽器的javascript/css文件的加載，尤其是需要盡可能的并行下載而且按照依賴關系先后執行。包括應用模塊，可以方便的通過這種加載機制延遲，按需，按時的加載到頁面中。
- 打包部署機制：由于依賴可追朔，這樣實際項目中用到的那些組件可以分析出來，最終可以根據實際使用到的情況打包出適合大小的組件庫，減小冗余包的存在。
- 模塊間的通信機制，由于模塊減輕耦合甚至是獨自孤立存在，組件之間的通信就非常重要，比如通常一個頁面上面的菜單組件實例點擊需要觸發下面組件的更新。如果直接監聽菜單事件去更新下面的組件，也許菜單是每個頁面都有。但是下面的組件不是每個頁面都有，這樣的事件監聽就顯然耦合較重，互相依賴對方的存在。如果菜單點擊這是告訴第三方我被點擊了。下面的組件只去監聽第三方的事件，這樣的代碼思路明顯要好過很多。
需要再次強調的是萬物皆模塊，這意味著通用組件本身實現是一個模塊，實際應用場景中的業務模塊也是模塊，都需要遵守模塊的約定。
6.前端的基本開發思想
取決于個人經驗：比如MVC的思想在組件實現過程中非常重要，Model通常是構造函數中那一堆配置信息，View通常是需要通過Model提供數據用戶呈現，實際上View上的操作的相應都需要Model來記住狀態。Controller用于操作二者。原理大家都知道，在開發中怎樣分清三者界限。保證思路清晰。
前端中javascript/css/html的角色也類似與MVC。下面的一些代碼方式就有違MVC的一些思想：
- css Expression:不僅IE only，更重要是CSS中寫javascript這個風格不對，難以維護。
- javascript直接修改style.xxx='xx'。能寫成css class的最好都寫成css class。
- html中直接寫onxxx="foo()"，沒有人能保證foo方法存在不被修改。
7.其他需要考慮的問題：
- 測試用例：通用組件庫是一個龐大的工程，也許牽一發動全身，不知道哪個API的變動會影響多少調用者，有充足的單側用例，一定程度上能保證整個組件庫的穩定性。
- 粒度：粒度是一個很值得思考的問題，其實html的標簽可以當做是一個小的組件，只是因為粒度很小，要完成一個復雜的應用，有很多的可復用組件都需要用到大片大片的重復html片段。另外一個極端，我們我們把整個頁面都寫成一個組件，顯然沒有復用性，跟沒封裝一樣。所以選擇一個合適的組件粒度，一個組件完成特定的功能，有利于搭建出有想象力的應用。
- 一致性：需要有很好的代碼規范和約定。才能保證API的一致性，用戶也會理所當然的想到怎樣用API，降低學習成本，一個最常見的例子就事件監聽的參數，建議統一為(eventObject,eventData)。
- 文檔&Demo:這個不用多說，沒有文檔和demo的東西沒有人去看代碼怎么使用。
- 性能：DOM操作是組件庫的性能殺手，高效的DOM操作尤其重要，事件監聽也是非常耗時的，建議能采用代理的都用父節點來代理。
- 資源釋放：組件的資源，引用是否能完全釋放？尤其是開發SPA，組件的資源內存釋放就非常重要了。
總結：
零零星星的提到了這么幾點，也是過去工作中的體會，當然會有不足，望大家補充，回頭可以check一下現在用到的一些框架/組件。歡迎討論。