前端組件化

在大型軟件系統中，web應用的先後端已經實現了分離，而隨着REST軟件架構的發展，後端服務逐步傾向於微服務，簡單來講就是將一個大型後端服務，拆分紅多個小服務，它們分別部署，下降了開發的複雜性，並且提升了系統的可伸縮性。而前端方面，隨着技術的發展，開發的複雜度也愈來愈高，傳統開發模式老是存在着開發效率低，維護成本高等的弊端。

那麼前端組件化開發都經歷了哪些階段呢？

 

2、 前端組件化開發發展之路

 

一、交互少的靜態頁面時期：公共模塊和CSS

 

 

 

這是一個很古老的時代，那時的前端頁面就是一些基本的HTML標籤以及JS和CSS，頁面上大部分都是一些靜態的文字，就在這個時期，前端JS和CSS已經出現了組件化，或許更多的應該成爲模塊化，即開發者把不一樣模塊的或者公共的JS和CSS放在不一樣的文件中，而後在頁面引入並使用，這種方式也沿用至今。

 

二、繁瑣的早期動態頁面時期：動態引入

 

 

 

因爲靜態頁面不能在頁面上存儲數據，閱讀者也不知足於基本的頁面交互，更但願頁面可以活起來，且可以把交互的數據存儲起來，因而出現了不少服務端技術，好比ASP，JSP。這些技術的出現使得前端頁面活起來了，用戶能夠根據本身的需求進行數據的交互。

 

然而這時的頁面上充斥着業務邏輯，隨着業務邏輯的增多，頁面的內容也愈來愈多，愈來愈複雜。在這個時期前端組件化開發獲得了必定的發展，開發者已經不知足於簡單的將JS和CSS文件模塊化，開始把一些公用的頁面邏輯獨立開來，而後經過頁面動態引入的方式進行使用，好比公共的頁面頭(header)和尾(footer)以及數據庫的鏈接(DatabaseConn.jsp)等。

 

三、後端爲主的MVC時期：Tag標籤

 

 

因爲早期動態頁面時期的業務邏輯都寫在頁面上，隨着邏輯的增多，頁面愈來愈複雜，維護起來也愈來愈難。因而以servlet爲表明的MVC時代逐漸登上歷史舞臺，這時頁面上的邏輯都被轉入到servlet中，使得View層的表現更加簡潔，也更加的易於閱讀，從而達到了開發的分層。

 

而隨着Struts以及spring的出現，MVC的開發方式達到鼎盛時期，前端View層的展示也變得愈來愈簡單，沒有了複雜的業務邏輯，前端的組件化方式主要是taglib標籤，好比jsp標籤，Struts標籤等，把HTML代碼和業務邏輯打包成一個標籤，而後使用者直接放置在想要的地方，就能夠了。但這個時期，整個WEB應用的開發輕前端重後端，那些taglib標籤也都是Java代碼編寫的。

 

四、前端Ajax時期：JS大行其道

 

 

 

 

因爲MVC時期的輕前端重後端的思想，前端頁面主要以表格的形式展示，若是想要一些很炫的效果，實現起來就比較複雜了，每每要寫一大堆的代碼，並且很難閱讀。AJAX做爲早已經出現的技術在這個時候愈來愈受到開發者的青睞，因而出現了不少的JS框架，好比jQuery-UI， easy-UI，miniUI以及大名鼎鼎的ExtJS。

 

這些JS框架的出現使得前端組件化的開發到達了一個新的高度，利用封裝Dom，AJAX以及頁面交互的方式，一個個的很炫的組件出現了，開發者能夠隨意的將這些組件應用的頁面中，開發變得簡單的同時頁面也變得愈來愈好看。因爲這些交互都由JS來完成，運行在瀏覽器端，也大大的減小了服務端的壓力，同時也提升了性能。

 

五、前端MV*時期：自定義組件

 

 

 

 

 

隨着時間的推移，開發者發現，若是想要修改這些（ExtJS，miniUI）JS框架中的組件是很是困難的，所以開發者但願可以很容易的自定義一些組件。這時以Angular，React爲表明的能夠自定義組件的JS框架出現了。這些框架的出現不只可讓開發者自定義組件，並且可讓開發者將已經存在的組件進行封裝。

 

不只如此，因爲有了npm以及bower這些包管理庫，開發者能夠很容易的將本身開發的組件publish到這些庫中，在使用時只要把他們下載下來（好比npm install）就能夠直接使用了。好比：

 

以上的組件化基本以HTML和JS爲主，那麼CSS怎麼作組件化呢？

 

六、CSS組件化：less和sass

 

 

 

前面講了CSS的模塊化基本上是將實現某一模塊Dom樣式的CSS放在不一樣的文件中，顯然隨着WEB應用的發展，開發者已經很不知足於這種簡單的模塊化了。 其實關於CSS的組件化，業界也早就已經有了不少探索，好比less，sass等。那麼爲何CSS也要組件化呢？ 

 

咱們知道CSS是一種扁平的結構，一個Dom可能對應着一個CSS樣式，而這些CSS樣式頗有可能出現公共的部分，那麼提取這些公共的部分也就實現了CSS的組件化，在諸如less和sass出現以前，開發者都是把公共的CSS樣式寫成一個個公共class，可是這樣以後CSS文件的閱讀性就變得困難了，固然也不容易修改。而less和sass出現以後，使得CSS的編程能夠定義變量，能夠實現繼承，CSS內容的結構也變得更加清晰，提升了CSS文件的閱讀性，更容易讓人理解，修改起來也變得簡單。

 

3、前端組件化的4個原則

 

前面講了組件化開發的發展過程，那麼咱們該怎麼作組件化呢？我認爲組件應該遵照如下幾個原則：

 

• 標準性

  任何一個組件都應該遵照一套標準，可使得不一樣區域的開發人員據此標準開發出一套標準統一的組件。

   

  
  

• 組合性

  組件以前應該是能夠組合的。咱們知道前端頁面的展現都是一些HTML DOM的組合，而組件在最終形態上也能夠理解爲一個個的HTML片斷。那麼組成一個完整的界面展現，確定是要依賴不一樣組件之間的組合，嵌套以及通訊。

  
  

• 重用性

  任何一個組件應該都是一個能夠獨立的個體，可使其應用在不一樣的場景中。

  
  

• 可維護性

  任何一個組件應該都具備一套本身的完整的穩定的功能，僅包含自身的，與其它組件無關的邏輯，使其更加的容易理解，使其更加的容易理解，同時大大減小發生bug的概率。

 

4、總結與實踐

 

固然組件化開發也並非這麼簡單就能實踐的。

 

• 對開發者的能力有必定的要求，好比傳統開發方式可能只要求開發者懂HTML，JS，CSS這些就能夠了，而組件化開發方式下還可能要求開發者掌握less，sass，或者ES6等的語法，以及webpack，glup等的前端打包以及構建工具。不過另外一方面，哪一個開發者不但願本身能掌握更多的本領呢？

   

  
  

• 技術選型，當前前端組件化框架能夠說是百家齊放，這就要求技術經理或者架構師具備超前的前瞻性，根據項目需求以及框架的將來發展進行分析選型。

 

以咱們公司目前在作的項目《普元數字化企業雲平臺》爲例，整個前端項目由上海和西安兩地的同事共4我的合做開發，在開發之初就確立了要採用一套統一的標準以減小異地開發的溝通成本，以及維護成本，顯然組件化開發能夠很好的知足此要求。

 

基於此，咱們的前端使用的是Facebook的React技術，React的核心是使用組件定義界面的表現，它突出的就是開發組件化。 以下圖所示，界面上的任何表現都對應着組件。組件之間很好的遵照了組件化開發的幾個原則，不一樣區域的同事開發出的組件都如同同一我的寫的，大大下降了異地的溝通成本和維護成本，以及提高了開發效率。