前言
一位計(jì)算機(jī)前輩曾說(shuō)過(guò)：

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

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

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

1.資源冗余

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

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

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

3.難于單元測(cè)試

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

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

舉例來(lái)說(shuō)，美團(tuán)頂部的搜索框就被實(shí)現(xiàn)為一個(gè)組件。

代碼構(gòu)成：

對(duì)比之前，可以看到組件化的一些特點(diǎn)：

1.按需加載

只加載必要的前端資源

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

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

3.易于測(cè)試

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

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

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

組件的生命周期：

一個(gè)組件的完整生命周期包括：

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

舉個(gè)例子，頁(yè)面初始化時(shí)組件的啟動(dòng)過(guò)程實(shí)際也是借助生命周期實(shí)現(xiàn)的：

回過(guò)頭來(lái)看，引入生命周期除了帶來(lái)擴(kuò)展性外，更重要的是理順了組件的各個(gè)階段，有助于更好的理解和運(yùn)用。

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

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

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

Flux
實(shí)現(xiàn)數(shù)據(jù)綁定后，美團(tuán)不得不面對(duì)另外一個(gè)問(wèn)題：如何協(xié)同多個(gè)組件間的數(shù)據(jù)。因?yàn)槟硞€(gè)組件的數(shù)據(jù)變化，很有可能引起其他組件的變化。例如當(dāng)修改購(gòu)買(mǎi)數(shù)量，總金額會(huì)變化，而總金額超過(guò) 500 后，還需要展示大額消費(fèi)提醒。

為了解決這個(gè)問(wèn)題，美團(tuán)引入了 Flux，使用全局消息總線的思路進(jìn)行跨組件交互。

例如因?yàn)榻换?fù)雜而一直讓美團(tuán)非常頭疼的項(xiàng)目購(gòu)買(mǎi)頁(yè)，在應(yīng)用組件 + Flux 重構(gòu)后，各模塊之間的互動(dòng)更加清晰：

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

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

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

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

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

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

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

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

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

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

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

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

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

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