剖析美團網(wǎng)站前端的組件化開發(fā)經(jīng)驗

前言
一位計算機前輩曾說過：

Controlling complexity is the essence of computer programming.
隨著前端開發(fā)復(fù)雜度的日益提升，組件化開發(fā)應(yīng)運而生，并隨著 FIS、React 等優(yōu)秀框架的出現(xiàn)遍地開花。這一過程同樣發(fā)生在美團，面臨業(yè)務(wù)規(guī)模的快速發(fā)展和工程師團隊的不斷擴張，美團歷經(jīng)引入組件化解決資源整合問題、逐步增強組件功能促進開發(fā)效率、重新打造新一代組件化方案適應(yīng)全棧開發(fā)和共享共建等階段，努力“controlling complexity”。本文將介紹美團組件化開發(fā)的實踐過程。

組件化 1.0：資源重組
在美團早期，前端資源是按照頁面或者類似業(yè)務(wù)頁面集合的形式進行組織的。例如 order.js 對應(yīng)訂單相關(guān)頁面的交互，account.css 對應(yīng)賬戶相關(guān)頁面的樣式。這種方式在過去的較長一段時間內(nèi)，持續(xù)支撐了整個項目的正常推進，功勛卓著。

隨著業(yè)務(wù)規(guī)模的增加和開發(fā)團隊的擴張，這套機制逐漸顯示出它的一些不足：

1.資源冗余

頁面的逐漸增加，交互的逐漸復(fù)雜化，導(dǎo)致對應(yīng)的 css 和 js 都有大幅度增長，進而出現(xiàn)為了依賴某個 js 中的一個函數(shù)，需要加載整個模塊，或者為了使用某個 css 中的部分樣式依賴整個 css，冗余資源較多

2.對應(yīng)關(guān)系不直觀

沒有顯而易見的對應(yīng)規(guī)則，導(dǎo)致的一個問題是修改某個業(yè)務(wù)模塊的 css 或者 js 時，幾乎只能依靠 grep?？咳藖砭S護頁面模塊 html、css 和 js 之間的依賴關(guān)系，容易犯錯，常常出現(xiàn)內(nèi)容已經(jīng)刪除但是 css 或 js 還存在的問題。

3.難于單元測試

以頁面為最小粒度進行資源整合，不同功能的業(yè)務(wù)模塊相互影響，復(fù)雜度太高，自動化測試難以推進。
2013 年開始，在調(diào)研了 FIS、BEM 等方案之后，結(jié)合美團開發(fā)框架的實際，美團初步實現(xiàn)了一套輕量級的組件化開發(fā)方案。主要的改進是：

1.以頁面功能組件為單位聚合前端資源
2.自動加載符合約定的 css、js 資源
3.將業(yè)務(wù)數(shù)據(jù)到渲染數(shù)據(jù)的轉(zhuǎn)換過程獨立出來

舉例來說，美團頂部的搜索框就被實現(xiàn)為一個組件。

代碼構(gòu)成：

對比之前，可以看到組件化的一些特點：

1.按需加載

只加載必要的前端資源

2.對應(yīng)關(guān)系非常清晰

組件所需要的前端資源都在同一目錄，職責(zé)明確且唯一，對應(yīng)關(guān)系顯著

3.易于測試

組件是具備獨立展現(xiàn)和交互的最小單元，可利用 Phantom 等工具自動化測試
此外，由于前端資源集中進行調(diào)度，組件化也為高階性能優(yōu)化提供了空間。例如實現(xiàn)組件級別的 BigRender、通過數(shù)據(jù)分析進行資源的合并加載等等。

組件化 2.0：趨于成熟
組件化 1.0 上線后，由于簡單易用，很快得到工程師的認(rèn)可，并開始在各項業(yè)務(wù)中應(yīng)用起來。新的需求接踵而來，一直持續(xù)到 2014 年底，這個階段美團稱之為組件化 2.0。下面介紹下主要的幾個改進。

Lifecycle
組件在高內(nèi)聚的同時，往往需要暴露一些接口供外界調(diào)用，從而能夠適應(yīng)復(fù)雜的頁面需求，例如提交訂單頁面需要在支付密碼組件啟動完成后綁定提交時的檢查。Web Components、React 等都選擇了生命周期事件/方法，美團也是一樣。

組件的生命周期：

一個組件的完整生命周期包括：

1.init，初始化組件根節(jié)點和配置
2.fetch，加載 css 和 js 資源
3.render，內(nèi)容渲染，默認(rèn)的渲染內(nèi)容方式是 BigRender
4.ready，進行數(shù)據(jù)綁定等操作
5.update，數(shù)據(jù)更新
6.destroy，解除所有事件監(jiān)聽，刪除所有組件節(jié)點
組件提供 pause、resume 方法以方便進行生命周期控制。各個階段使用 Promise 串行進行，異步的管理更清晰。使用自定義語義事件，在修改默認(rèn)行為、組件間通信上充分利用了 YUI 強大的自定義事件體系，有效降低了開發(fā)維護成本。

舉個例子，頁面初始化時組件的啟動過程實際也是借助生命周期實現(xiàn)的：

回過頭來看，引入生命周期除了帶來擴展性外，更重要的是理順了組件的各個階段，有助于更好的理解和運用。

Data Binding
數(shù)據(jù)綁定是美團期盼已久的功能，將 View 和 ViewModel 之間的交互自動化無疑會節(jié)省工程師的大量時間。在組件化減少關(guān)注點和降低復(fù)雜度后，實現(xiàn)數(shù)據(jù)綁定變得更加可能。

美團最終實現(xiàn)的數(shù)據(jù)綁定方案主要參考了 Angular，通過在 html 節(jié)點上添加特定的屬性聲明綁定邏輯，js 掃描這些內(nèi)容并進行相應(yīng)的渲染和事件綁定。當(dāng)數(shù)據(jù)發(fā)生變化時，對應(yīng)的內(nèi)容全部重新渲染。

使用屬性聲明綁定邏輯的好處是可以同時支持后端渲染，這對于美團團購這樣的偏展現(xiàn)型業(yè)務(wù)是非常必要的，用戶可以很快看到頁面內(nèi)容。

Flux
實現(xiàn)數(shù)據(jù)綁定后，美團不得不面對另外一個問題：如何協(xié)同多個組件間的數(shù)據(jù)。因為某個組件的數(shù)據(jù)變化，很有可能引起其他組件的變化。例如當(dāng)修改購買數(shù)量，總金額會變化，而總金額超過 500 后，還需要展示大額消費提醒。

為了解決這個問題，美團引入了 Flux，使用全局消息總線的思路進行跨組件交互。

例如因為交互復(fù)雜而一直讓美團非常頭疼的項目購買頁，在應(yīng)用組件 + Flux 重構(gòu)后，各模塊之間的互動更加清晰：

其他方面的改進還有很多，包括引入模板引擎 LightnCandy 約束模板邏輯、支持組件任意嵌套、支持異步加載并自動初始化等。

隨著組件化 2.0 的逐步完善，基本已經(jīng)可以從容應(yīng)對日常開發(fā)，在效率和質(zhì)量方面都上了一個臺階。

組件化 3.0：重啟征程
時間的車輪滾滾前行，2014 年底，美團遇到一些新的機遇和挑戰(zhàn)：

基于 Node 的全棧開發(fā)模式開始應(yīng)用，前后端渲染有了更多的可能性
YUI 停止維護，需要一套新的資源管理方案
新業(yè)務(wù)不斷增加，需要找到一種組件共享的方式，避免重復(fù)造輪子
結(jié)合之前的實踐，以及在這一過程中逐漸積累的對業(yè)內(nèi)方案的認(rèn)知，美團提出了新的組件化方案：

基于 React 開發(fā)頁面組件，使用 NPM 進行分發(fā)，方便共建共享
基于 Browserify 二次開發(fā)，建設(shè)資源打包工具 Reduce，方便瀏覽器加載
建設(shè)適應(yīng)組件化開發(fā)模式的工程化開發(fā)方案 Turbo，方便工程師將組件應(yīng)用于業(yè)務(wù)開發(fā)中

React
在組件化 2.0 的過程中，美團發(fā)現(xiàn)很多功能和 React 重合，例如 Data Binding、Lifecycle、前后端渲染，甚至直接借鑒的 Flux。除此之外，React 的函數(shù)式編程思想、增量更新、兼容性良好的事件體系也讓美團非常向往。借著前端全棧開發(fā)的契機，美團開始考慮基于 React 進行組件化 3.0 的建設(shè)。

NPM + Reduce
NPM + Reduce 構(gòu)成了美團新的資源管理方案，其中：

NPM 負(fù)責(zé)組件的發(fā)布和安裝?？梢哉J(rèn)為是“分”的過程，粒度越小，重用的可能性越大
Reduce 負(fù)責(zé)將頁面資源進行打包?？梢哉J(rèn)為是“合”的過程，讓瀏覽器更快地加載
一個典型的組件包：

只要在頁面中 require 了 smart-box，經(jīng)過 Reduce 打包后，js、css 甚至圖片、字體，都會出現(xiàn)在瀏覽器中。

整體思路和組件化 1.0 如出一轍，卻又那么不同。

Turbo
單單解決分發(fā)和打包的問題還不夠，業(yè)務(wù)開發(fā)過程如果變得繁瑣、難以 Debug、性能低下的話，恐怕不會受到工程師歡迎。

為了解決這些問題，美團在 Node 框架的基礎(chǔ)上，提供了一系列中間件和開發(fā)工具，逐步構(gòu)建對組件友好的前端工程化方案 Turbo。主要有：

1.支持前后端同構(gòu)渲染，讓用戶更早看到內(nèi)容
2.簡化 Flux 流程，數(shù)據(jù)流更加清晰易維護
3.引入 ImmutableJS，保證 Store 以外的數(shù)據(jù)不可變
4.采用 cursor 機制，保證數(shù)據(jù)修改/獲取同步
5.支持 Hot Module Replacement，改進開發(fā)流自動化
6.通過這些改進，一線工程師可以方便的使用各種組件，專注在業(yè)務(wù)本身上。開發(fā)框架層面的支持也反過來促進了組件化的發(fā)展，大家更樂于使用一系列組件來構(gòu)建頁面功能。

小結(jié)
發(fā)現(xiàn)痛點、分析調(diào)研、應(yīng)用改進的解決問題思路在組件化開發(fā)實踐中不斷運用。歷經(jīng)三個大版本的演進，組件化開發(fā)模式有效緩解了業(yè)務(wù)發(fā)展帶來的復(fù)雜度提升的壓力，并培養(yǎng)工程師具備小而美的工程思想，形成共建共享的良好氛圍。毫無疑問，組件化這種“分而治之”的思想將會長久地影響和促進前端開發(fā)模式。美團現(xiàn)在已經(jīng)準(zhǔn)備好，迎接新的機遇和挑戰(zhàn)，用技術(shù)的不斷革新提升工程師的幸福感。