大話前端組件化

發布時間：2021-06-22 15:26:45

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

  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階段，前端渲染將成主流。搜索引擎勢必推出新的機制對新的信息進行收錄。