大話前端組件化

  在軟件工程中系統的架構也在隨着規模不斷的演進，最初的面向過程的軟件開發到如今面向對象的軟件開發。軟件工程也逐漸進入組件化開發階段。然而前端的組件化的發展一直滯後，傳統的桌面開發早已經進入組件化開發階段。

  Web1.0時代前端主要是HTML與CSS的天下，JS則是簡單的輔助工具而已。到了Web2.0時代前端開始走向以AJax技術爲核心輕量級別交互，以JQuery、ExtJS、Dojo表明前端類庫（後二者爲框架）爲導向的開發開始迅猛發展。JQuery在前端領域叱吒風雲多年，人們都紛紛認爲JQuery望風披靡。而ExtJS、Dojo在UI組件上作的面面俱到，對於當時的管理類Web系統來講也是福音。同時也看見前端組件化初見苗頭（實現了一些初級的組件化開發模式，如：jQuery的擴展...），人們都紛紛意識到前端組件化帶來的巨大好處。

  到了Web2.0後半頁移動互聯網的迅速崛起，交互從傳統的PC轉到移動端。而移動端對於交互性與性能的要求也要比PC端強的多。同時瀏覽器的信息量也愈來愈大，傳統的框架與類庫已經不堪重負。已經沒法保證前端維護性與性能。

  人們就開始思考前端已經早已不是類庫能解決的問題了，前端已經成爲一個工程化的問題。第一代前端框架涌現出來，以Knockout.js、Ember.js、Backbone.js爲表明。第二代前端框架：以Angular.js、React.js、Vue.js、Avalon.js。第二代前端框架幾乎以MVVM爲導向，除了React.js。以React.js與Vue.js爲表明的前端框架已經使用了組件化的思路進行開發軟件，圍繞組件進行業務架構。

Angular.js 1.x架構圖

Avalon.js 1.x架構圖

Vue.js 1.x架構圖

React.js 15.x架構圖

  在前端進入組件化的階段的同時也遇到了很多的問題，這些問題在傳統的桌面端早已經不是問題。前端組件化主要面對如下問題：組件與子組件通信、可視化組件的外觀可維護性、複雜組件的可維護性、組件與組件的隔離性等。組件化意在解決業務開發人員在開發業務時無需關心組件內部細節進行快速的使用組件進行設計業務，組件化能夠說是對面向對象編程的完整實現。

  組件化對Web開發有着深遠的影響，直接影響到Web的設計、維護、測試，組件的切分，組件的開發。傳統的網頁開發模式將被推倒重來。新型的組件也將從新發明，從新發明輪子是不可避免的。同時組件也要兼顧各個消費端的需求。組件由單一服務於PC轉向任何支持瀏覽器的平臺。

  目前來看，組件化的的實現分兩路：以模板驅動JS爲表明的Angular、Vue、以JS驅動的React，同時以Web Component原生瀏覽器特性驅動的框架也在崛起Polymer、Nova。不得不說原生或兼容原生的組件化纔是將來。

Web應該具有原生可視化程序的那些特徵？

  組件化：

  組件化是核心之中核心，爲何要組件化？之前咱們在Web端作的UI都很直接而簡單。界面都是Div套上去搞定，取值都是「$(xx).xxx」。這種模式在幾年看開發速度確實很快。可是客戶的需求複雜之後，要你在Div裏修改內容。並且一樣的東西不止出如今一個地方。當時若是要去解決，無非兩種辦法，第一Copy幾份，第二作個相似JQuery擴展的，將相同的東西抽象在一塊兒，而後「$xxx(div)」後它就變成你想要的部件。其實到這裏Web已經進化了一點點，能夠重用大部分的代碼了，那它究竟算不算真正的組件呢？答案很簡單：不算。可能你要問爲何不算？

  當前你進一步接觸需求後，客戶要求你可以將DivA中的某個地方加上BDiv，而BDiv不是何時都會出現。或者讓你嵌套多層。而後每一層的功能都不太同樣。這時候應該就頭痛了。擴展的代碼就至關冗餘了很難維護，並且樣式很難修改。爲何會這樣呢？其實緣由很簡單，由於你一直認爲Web上全部的東西在同一層。並無將它們按層次劃分來進行管理。因此之前看到的組件都是「僞組件」。下面一幅圖將展現真正的組件結構。

真正的組件該有的樣子

  上面這個圖若是用傳統的實現思路應該是比較頭痛的。須要作不少封裝才能達到這個界面。但若是將它們一層層的拆開來實現，而後就像搭積木同樣，有層次的拼在一塊兒。這個問題就可能變的簡單。若是每一個組件均可以封裝而且嵌套，上層組件之間只須要關心它須要的下層組件的屬性和方法就好了。這樣思惟就頗有層次，不在頭痛如何組織的問題。

  組件化還有一個意義在於把相同的功能抽象成基本的另外一個組件，而後多個相似組件均可以去繼承它，並作個性化的擴展定製。

  組件化是至關美好的東西，解決了標準化的問題。可是Web要實現談何容易。並且要讓每一個開發者都很快掌握，這樣的框架實現也是至關困難。

  隔離性：

  Web的CSS，JS，DOM都是很平直的東西。均可以直接影響。若是要作組件，那麼須要將組件進行隔離。樣式須要隔離，DOM須要隔離。這樣組件與組件之間纔不會產生干擾。

  可測試性：

  Web的測試遠遠沒有原生應用的測試作的好，若是要進行組件化，那麼對每一個組件，尤爲是嵌套組件與組合組件的測試尤爲重要。好的框架應該能快速定位組件，以及方法。很好的展現當前組件的結構，便於修改問題。

  劃分性：

  重用公用基礎的組件，根據需求搭建面向業務的組件與重構新的組件，這樣組件化的真正生產力才能發揮出來，可是要能作到靈活開發，這樣的框架實現談何容易。

  非入侵性：

  新的組件放在舊的業務，要保證融合，這樣的框架才能知足現有的需求，若是每次升級都要完全拋棄舊的東西，這樣對開發來講也是巨大的工做量。

  學習臺階：

  之前Web端都是前端開發或UI設計作HTML模板，後端套模板。若是如今將這些開發都放在前端，前端必須掌握必定的JS和框架的知識。若是讓一個之前寫HTML的接觸這樣的框架。若是他們不能理解那麼這樣的框架真的好嗎？

組件化僅僅只是前端邁向標準化的一個開始！

  若是說組件化框架是骨架，保證各個組件的獨立性，那麼業務就是靈魂。凝聚不一樣的部件。業務不只僅須要輸入輸出的組件，須要一套能適應Web端的業務架構，保證業務與組件分離，這樣業務才能高效重用，界面更換應該不影響前端的業務部分。

尾巴：

  到目前爲止前端領域依然是火熱的造輪子階段，誰也不比誰好，你有張良計我有過牆梯，都有本身不足的地方。組件化的浪潮勢必可擋，以React與Vue表明的組件化框架最有但願成爲出色的工具。可是在前端蓬勃發展（打爛仗）時代相信會有更好的輪子解決他們沒有解決的問題。

  前端框架真正要解決的問題是開發效率與維護效率，而目前的框架主要解決組件的重用性與運行效率。真正開發問題其實是卡在不斷製造業務層的輪子與框架的使用門檻與組件的維護效率。沒有一套完善的前端框架對效率的提高仍是頗有限的，否則仍是在走之前的老路，只是路好走了點，解決了一個問題，其餘各類問題出來了，抵消掉了框架的優點。那也算不上革命的創新。

  前端組件化頗有可能將Web帶到3.0階段，前端渲染將成主流。搜索引擎勢必推出新的機制對新的信息進行收錄。