我來聊聊面向組件的前端開發

本文首發於 歐雷流。因爲我會時不時對文章進行補充、修正和潤色，爲了保證所看到的是最新版本，請閱讀 原文。

看到標題，通常會有兩種反應：

「哇～好高大上啊！」

「嗯，這個話題真大……」

——的確如此。

深情前戲

我不生搬硬套那個什麼百科來講啥是「面向組件」和爲啥這麼作，而是從工做現狀以及本身思考的角度來闡述，並試着擬出一個解決方案。

前端眼裏的「組件」

對於前端開發人員來講，「組件」一般就是指頁面上的 UI 組件，主要包括外觀和交互。一個合格的組件應該是可複用、可定製、鬆耦合的，它可以表明一個事物，能夠完成一個動做。

組件能夠很簡單，也能夠很複雜。按照複雜程度從小到大排的話，能夠分爲幾類：

1. 基礎組件；
2. 複合組件；
3. 頁面；
4. 應用。

對，不用揉眼睛，你沒有看錯！

站在更高的角度去看，「頁面」和「應用」也是一種「組件」，只不過它們更爲複雜。在這裏我想要說的不是它們，而是「基礎組件」和「複合組件」。

其中，基礎組件具備簡單的外觀和基礎的功能，而複合組件則是根據具體場景所進行的基礎組件的組合和封裝。

爲啥要「面向組件」

在從事一段時間的前端開發以後，就會發現：

「一個系統裏的頁面功能怎麼都差很少？」

「每一個網站基本都一個模子裏刻出來的！」

——說得沒錯！

你在 CTRL + C 並 CTRL + V，改掉相同中的不一樣以後，保存文件並刷新頁面，點這點那看看效果——「我靠！這倆頁面的交互一毛同樣，怎麼在那個頁面好好的，到這裏就很差使了？！」

1……2……3……個小時過去了，這該死的小強究竟是從哪裏溜進來的一點兒頭緒也沒有……內心窩火地一直在「MMP」，一不當心說漏了嘴——「媽賣批的！！！」

兄弟，淡定！

出現這種問題，是由於沒有面向組件開發。那些你所以爲的「類似」的部分，就能夠提取出來造成組件，以備再次出現相似場景時使用。你以往所依賴的「CTRL + C / V 大法」，講道理，是下下策中的下下策。

等組件積累得多了，頁面就再也不是本身苦思冥想一行一行代碼擠出來的，而是隨手從現成的庫中拿來一個一個組件拼出來的。如此一來，不只頁面功能更加穩定，前端開發也能脫離枯燥而變得更加有趣，告別那一成天大部分時間在摁臭蟲的鬼日子——

後端：「何時能夠聯調？」

前端：「頁面早就弄好了，接口呢？」

後端：「……」

「面向組件」是啥啊

換個詞，「組件化」，也許更爲熟悉。但，因此，究竟是指什麼呢？

對於抽象概念的含義，每一個人都會有本身的理解，正所謂「一千個讀者心中有一千個哈姆雷特」。有人會說：

就是把相關的 HTML、CSS、JS 和圖片等文件放到同一個文件夾裏吧？

——沒啥毛病。

在進行面向組件開發時，確實會將同一個組件的相關文件放在一個文件夾中，然而，這並非核心。重要的是，可以將一個複雜的東西恰如其分地拆分紅更小且獨立的，高內聚低耦合，讓別人沒必要了解其內部運做原理拿來就用——這是思想，也是能力。

進入正題

「面向組件」開發，或者說「組件化」，由來已久，並不新鮮。這個話題在前端圈兒也炒了不少年了，這個框架那個庫的層出不窮，爲何我如今還要再拿出來嚼一遍呢？

理由很簡單：

1. 在別人那不成問題的，在我這可能非常問題；
2. 對別人很管用的工具，對我可能並不太適用。

別人爽的姿式我不爽

要進行面向組件開發，前提是得有可行的技術方案，依我看，須要必備幾點：

• 組件的樣式和交互不會意外地被外界干擾——對外隔離；
• 一個組件相關的資源要在我用到時再給我——按需加載；
• 讓前端技術不那麼強的後端開發也能夠用——門檻低。

紅極一時的充分發揮 jQuery 特長的兩個寶兒，jQuery UI 和 Bootstrap 提供了不少 UI 組件，對後端開發人員也很友好，看起來符合要求。但從它們組件的實現方式以及資源加載形式來看——

• jQuery UI
• Bootstrap

如今的前端圈兒，一提到「組件」，大多數人的興奮點都在 React、Vue、Angular 等 MV* 框架上。它們是很不錯，不只知足了「對外隔離」和「按需加載」，還大大地提高了前端開發的效率，能大紅大紫成這樣自有其道理。

我司的業務是 to B 的，所以前端開發場景很「明確」，基本能夠簡單粗暴地理解爲：「前臺」就是移動端，「後臺」就是桌面端。

前臺開發用的是基於 React 和 Ant Design Mobile 二次開發的框架。It works well，可以 hold 住當前的需求。然而，後臺開發就不同了。

咱們後臺的需求不少，比前臺多，而且源源不斷地加速增加；咱們後端的人員不少，比前端多，而且不成比例地持續加人。這就致使了一些問題：

• 每條業務線的前、後端開發人員比例平均爲 1:4；
• 一個前端人員可能會去支持一條業務線的多個項目；
• 一個前端人員可能會去支持多條業務線。

——人不夠用！

該如何去解決呢？從公司的角度出發，確定是要下降成本——不靠招更多的人，而是靠改進方法最大化利用已有資源——讓前端人員可以寫更多頁面，讓後端人員也能寫頁面。

爲了達到上述目的，我在 jQuery 和 Bootstrap 的基礎上封裝了一個用於後臺的框架。

雖然在寫 JS 時已經節省不少時間，也有幾個後臺系統是由後端人員獨立開發的，但仍是要寫一堆 HTML 代碼。就連前端人員都會以爲有點心煩，更別說後端人員望而卻步了。

在使用 React 組件時能夠少寫很多 HTML 標籤，但是，但但是，後端開發人員會去寫嗎？他們會想寫？！

綜上所述，MV* 類框架並不能解決我司後臺現階段所存在的問題——

• React
• Vue
• Angular

有人不滿了：

你這也不行，那也不行，那還有啥了？！

——大大的有！

你們爽的姿式才正確

有那麼一個被各類 MV* 框架的光輝所掩蓋的，雖然有那麼點缺陷但卻頗有實力且頗具潛力的技術——是的，就是 Web Components！光從名字來看，不難想象它正是爲了解決前端組件的問題而出現的。

Web Components 由能夠彼此分開使用也可以協同工做的四個部分組成：

• Custom Elements——定義新的 HTML 元素；
• Shadow DOM——隔離 DOM 和樣式；
• HTML Imports——聲明要引入的 HTML 文檔；
• HTML Templates——定義可複用的 HTML 片斷。

由於是 W3C 的親兒子，使用者能夠像對其餘如 <div>、<p> 同樣對待由 Web Components 封裝的組件——徹底照顧了前端技術不嫺熟的後端開發大大們。

被你說得那麼神，我咋就沒據說過呢？？？

——問得很好。

既然是 W3C 親兒子，從出生到被世間，尤爲是被那些「有權有勢」的所承認須要時間——它出來多年仍未成爲推薦標準，兼容性不太理想。

能夠說，兼容性和不穩定性成了推廣 Web Components 的致命傷。

然而，並不用以爲過於掃興。

已經有 polyfill 幫咱們填了一些坑，而且還有幾個簡化開發的庫，如：Polymer、X-Tag 和 Skate 等。再加上，我司的後臺是對內的，幾乎只需考慮 Chrome 類瀏覽器，兼容性缺陷基本能夠無視。

這樣一來，開發一套基於 Web Components 的組件，是否是既讓前端人員爽了，又讓寫頁面的後端人員爽了呢？

內心美滋滋〜( *´艸｀)

高潮來了

如今看來，前端團隊的面向組件開發的技術方案彷佛已經肯定了：

• 移動端用 React 和 Ant Design Mobile；
• 桌面端用 jQuery、Bootstrap 和 Web Components。

若是覺得這樣就行了，那真是 think too much！

除了啪啪啪，什麼都要快！

隨着公司業務的發展，已經將觸角伸向了正不斷髮力的微信小程序。雖然目前在這方面的業務不多，但我相信相關需求會接踵而至。

衆所周知，微信小程序的開發自成體系，對於咱們前端開發人員來講又多了一個東西要去學……不過，做爲一名前端工程師，早就習慣了這比女人的心情還變幻莫測的前端技術。

稍微往遠點看，若是公司的業務須要，可能還會要作出來沒多久的支付寶小程序。沒準將來又出現了別的什麼小程序，或者其餘具有組件特性的新的什麼輪子。

爲了支持公司的業務，每出來一個新的東西，前端人員就不得不去學怎麼去用而且用好它。從團隊管理、團隊協做以及開發效率等方面來看，會產生一些嚴重的問題：

• 得每一個人都掌握所用到的庫/框架才能任意分配任務；
• 技術棧雜亂而不便於進行培訓和代碼質量管理；
• 抽取沉澱組件庫將要變得異常艱難。

這些問題在快速發展的業務的催化下，就會致使：

• 開發時間太少啊太少——加班！加班！！加班！！！
• 前端人員不夠啊不夠——加班！加班！！加班！！！

要是加班還解決不了怎麼辦？那就項目延期唄。

可項目延期會耽誤公司的業務啊！那就……

想個新姿式

爲了規避以上問題，爲了以不變應萬變，爲了讓支持業務的前端開發童鞋可以無視運行環境而有始終如一的便捷開發體驗，我試着想了一個解決方案——通用組件編寫規範。

所謂的「通用組件編寫規範」主要包含兩部分：組件定義和目錄結構。

組件定義使用 ES6+ 語法，採用類的方式，要兼顧組件的屬性映射、數據綁定、事件處理、生命週期等特性。類的各成員的設計參考現有流行庫/框架，但不一樣於它們。

目錄結構遵守前端開發的「關注點分離」原則，一個目錄表明一個組件，一個 JS 文件就是一個組件定義。組件的樣式用 Sass 來寫。

通用組件編寫規範解決的是開發階段的問題，是支持業務的前端童鞋所要重點關注的，接下來的事情就交給構建工具去完成。

賢者時間

正如開頭所說，「面向組件」開發是一件很高大上、很大的話題，想搞出一套「Write once, Run anywhere」的組件開發方案更是聽起來天方夜譚。

我已經作好了被各類潑冷水的心理準備，也許在實現的道路上困難重重、踩坑無數，到最後被證明這確實是異想天開；但爲了能讓公司業務的發展不受前端開發的阻礙，讓團隊中的小夥伴們減小加班次數，關於團隊留下更多美好的記憶，不會放棄前端開發這條不歸路，我願去一試！！！

要發車了，沒時間作更多解釋了！

---

歡迎關注微信公衆號以及時閱讀最新的技術文章：