摘要：另一種關(guān)于組件的常見說(shuō)法，是組件是為了重用。這件事情是前端特有的，受限制于的結(jié)構(gòu)。這一節(jié)的題目叫做混亂的組件通訊，我們來(lái)仔細(xì)掰扯一下細(xì)節(jié)，因?yàn)榻M件模型雖然很常說(shuō)但是對(duì)通訊過(guò)程沒有約定。

這個(gè)話題很難寫。

但是反過(guò)來(lái)說(shuō)，愛因斯坦有句名言：如果你不能把一個(gè)問題向一個(gè)六歲孩子解釋清楚，那么你不真的明白它。

所以解釋清楚一個(gè)問題的關(guān)鍵，不是去擴(kuò)大化，而是相反，最小化。

Let"s begin.

組件不是一個(gè)很清晰的編程概念。UML里的組件圖基本上就是一個(gè)圖示，遠(yuǎn)不能和具有數(shù)學(xué)完備性的State Diagram相比，也不能和靜態(tài)結(jié)構(gòu)的Class Diagram和時(shí)序交互的Sequence Diagram相比。但大家通常還是會(huì)畫一個(gè)出來(lái)，便于程序員理解系統(tǒng)的運(yùn)行時(shí)結(jié)構(gòu)，或者代碼結(jié)構(gòu)。

你很容易在Google里搜索到一些Component Diagram的圖例，所以這里不貼圖了。你在組件圖上可以看到有這樣一些概念是重要的：

port，它指的是包含一組相關(guān)函數(shù)的接口，一個(gè)interface或者一個(gè)protocol；

user和provider，誰(shuí)提供port和誰(shuí)使用port；

這兩個(gè)概念都不需要很復(fù)雜的闡述，直覺的理解沒問題；

但問題是他們定義得特別粗，接口怎么實(shí)現(xiàn)的？是function call？rpc？message passing？event？沒說(shuō)，事實(shí)上是都行。

常見的Component Diagram畫的一般是run-time的instance，black box邏輯，強(qiáng)調(diào)的是instance之間的依賴關(guān)系。

另一種關(guān)于組件的常見說(shuō)法，是組件是為了重用。這把問題聊到了另一個(gè)空間去了。重用是靜態(tài)概念，它指的是代碼里的一個(gè)模塊，類、結(jié)構(gòu)等等，而不是指run-time實(shí)例。

但是這兩種說(shuō)法不矛盾。因?yàn)楹诵牡膯栴}，無(wú)論運(yùn)行時(shí)還是靜態(tài)代碼，組件首先強(qiáng)調(diào)的是黑盒思維，這點(diǎn)不是問題，封裝是開發(fā)者熟悉的邏輯；但是組件必須集成為系統(tǒng)，無(wú)論在靜態(tài)代碼層面還是運(yùn)行時(shí)，組件之間都有依賴關(guān)系，在項(xiàng)目具有一定規(guī)模時(shí)這尤其重要。

在靜態(tài)代碼層面，任何語(yǔ)言都有庫(kù)和源碼模塊話機(jī)制，include，import，require等語(yǔ)法關(guān)鍵字或函數(shù)建立了這種依賴關(guān)系；在運(yùn)行時(shí)，組件（或?qū)ο髮?shí)例）之間可能有動(dòng)態(tài)產(chǎn)生的綁定關(guān)系；A對(duì)象要具有B的引用，才能使用B的方法；或者要降低耦合，采用觀察者模式，消息總線或消息路由，Pub/Sub，等等。相對(duì)而言，后者更為重要一些，前者你總能通過(guò)分拆模塊避免循環(huán)，靜態(tài)依賴關(guān)系總歸是比較清楚的，它定了就定了，不會(huì)運(yùn)行時(shí)發(fā)生變化。

所以這篇文章主要談運(yùn)行時(shí)組件依賴關(guān)系的處理，特指在一個(gè)應(yīng)用之內(nèi)，不是微服務(wù)或者多個(gè)服務(wù)器組成的分布式系統(tǒng)。

可能可以不用一上來(lái)就談React，但是這樣做最簡(jiǎn)單。

React的基本代碼單元稱為React Component；它聲稱是View Component，但也可以是純state的Component，在render方法里render其他view component即可；有經(jīng)驗(yàn)的React開發(fā)者知道這被社區(qū)稱為Container Component。

如果從Component的角度看，React的Component有一個(gè)非常特別的設(shè)計(jì)：Component之間只有一種通訊機(jī)制！就是通過(guò)Props傳遞對(duì)象或函數(shù)，原則上Component之間是不會(huì)通過(guò)引用互相調(diào)用方法甚至發(fā)送消息的。換句話說(shuō)，所有Component都是匿名的。開發(fā)者不該在運(yùn)行時(shí)查找某個(gè)Component實(shí)例訪問其數(shù)據(jù)或方法，調(diào)用其方法的只有React框架。

從這個(gè)意義上說(shuō)，React象一個(gè)Inversion of Control（IOC）模式，所有有態(tài)組件都插在React框架之上，他們可以在willReceiveProps或者render方法被調(diào)用時(shí)獲得傳遞進(jìn)來(lái)的數(shù)據(jù)或方法，他們也可以通過(guò)調(diào)用setState方法觸發(fā)一次更新，但這幾乎就是全部了。

React的官方開發(fā)者提供了一套叫做flux的數(shù)據(jù)流方式，需要持久化（生命周期比視圖長(zhǎng)）的狀態(tài)存入store，社區(qū)也有很多改良的工作，包括流行的redux，mobx等等；但是本質(zhì)上說(shuō)，react自己具有完備的態(tài)處理能力，只要把兩個(gè)有相關(guān)性的組件的關(guān)聯(lián)狀態(tài)放到他們的共同祖先即可；只是這樣做，如果沒有特殊的處理的化并不靈活，在設(shè)計(jì)變更時(shí)大量代碼要修改，還不如使用redux等框架來(lái)得方便；anyway，這一點(diǎn)不是我們這篇文章要討論的主題，它指的是靜態(tài)代碼層面的模塊化問題，我找時(shí)間寫文章專述。我們回到React組件是如何組合和互動(dòng)這個(gè)話題上。

我們重新強(qiáng)調(diào)一下React組件的匿名問題。對(duì)一個(gè)組件而言，它要能工作，當(dāng)然需要和外部組件互動(dòng)，但是React組件在這里做了一個(gè)極致的設(shè)計(jì)：

一切依賴性都是注入的；注入的依賴性來(lái)自哪個(gè)外部組件，組件內(nèi)部一無(wú)所知。

依賴性注入（Dependency Injection）一詞，對(duì)熟悉可測(cè)試性（tesability）的開發(fā)者來(lái)說(shuō)不陌生，但大多數(shù)情況下這停留在測(cè)試領(lǐng)域，很少影響設(shè)計(jì)。絕大多數(shù)應(yīng)用在頂層都有一些類似全局變量的模塊，也就是組件圖中表達(dá)的那些；使用這些模塊的其他模塊都能用全局的name找到它們，找到就可以使用了。但是在React里，NO! 即使在頂層，每個(gè)組件的外部依賴也都是注入的。

所以你看到React的組件模型實(shí)際上只包含三個(gè)元素：

父組件向子組件傳遞的prop是對(duì)象或值

父組件向子組件傳遞的prop是方法（bound）

父子組件們用一個(gè)tree表示，是單向的傳遞數(shù)據(jù)或方法的（即層層注入）

我們先說(shuō)第一個(gè)要素：父組件向子組件傳值。本質(zhì)上，它是子組件對(duì)父組件或父組件可觀察的某個(gè)資源狀態(tài)的一個(gè)觀察。

從語(yǔ)法上來(lái)說(shuō)，它比寫Observer Pattern要來(lái)得方便，因?yàn)樽咏M件沒有Subscribe的負(fù)擔(dān)，是反過(guò)來(lái)做的，父組件把子組件的依賴性（需要觀察的對(duì)象）塞進(jìn)來(lái)。

因?yàn)镽eact是function programming風(fēng)格，這樣寫更方便；不方便的地方是觀察變化的邏輯是在willReceiveProps里，需要自己比較新版本和副本的區(qū)別，如果有差別，調(diào)用setState方法更新自己。

但是這種觀察能實(shí)現(xiàn)所有需要的觀察嗎？比如SomethingStarted，SomethingResumed，SomethingOpened？

確實(shí)可能遇到一些棘手的情況難以簡(jiǎn)單用值的變化來(lái)表述一種變化，但是我們反過(guò)來(lái)想這個(gè)問題，數(shù)據(jù)庫(kù)是用CRUD實(shí)現(xiàn)的，Restful API設(shè)計(jì)采用資源建模也只有有限的verb，他們都工作的很好；工作的好的原因是他們都是用資源而不是行為建模的，如果確實(shí)需要為行為建模，我們也可以使用狀態(tài)機(jī)，對(duì)單一模塊而言，在各種粒度上狀態(tài)機(jī)都是很好的建模方式；在狀態(tài)機(jī)模型下，狀態(tài)就一定可以用離散值來(lái)表示，比如運(yùn)行狀態(tài)可以是started, stopped, resumed, failed，等等。

這樣的建模方式是否比自己發(fā)明很多message類型更為有效呢？個(gè)人看法是的，這是一種遠(yuǎn)好于用行為語(yǔ)義定義事件的方式。無(wú)論crud還是restful都有極為廣泛的實(shí)踐，可以被認(rèn)為是被證實(shí)可行的方式。

從這些意義上說(shuō)，React的組件建模方式具有類似crud或http verb的統(tǒng)一抽象，是避免出現(xiàn)大量程序員自己發(fā)明混亂語(yǔ)義的好辦法。

父組件向子組件傳遞的Bound方法，應(yīng)該看作是父組件向子組件提供的一種觸發(fā)狀態(tài)變化的代理。比如你去酒店，你叫服務(wù)生來(lái)開門，這是一種類似function call或者message passing的機(jī)制，但是服務(wù)生也可以給你一張卡你自己去開門，這就是一種代理；和觀察資源一樣，因?yàn)槭褂昧私y(tǒng)一的Prop機(jī)制，在組件內(nèi)部看，這種代理也是匿名的，組件并不知道到底是誰(shuí)在提供這項(xiàng)功能，它只是在需要的時(shí)候使用而已。

這件事情是前端特有的，受限制于HTML的結(jié)構(gòu)。

很多功能組件都不只是基于觀察邏輯工作，他們還會(huì)需要提供功能性服務(wù)，功能性服務(wù)的入口從哪里觸發(fā)，看應(yīng)用和系統(tǒng)結(jié)構(gòu)而定，它可能來(lái)自用戶操作，可能來(lái)自操作系統(tǒng)，也可能來(lái)自API請(qǐng)求，后面我們還會(huì)仔細(xì)說(shuō)這個(gè)問題。

事實(shí)上絕大多數(shù)App，其組件都是可以用一個(gè)tree來(lái)表示的，只不過(guò)在項(xiàng)目規(guī)模不大的時(shí)候，大家更喜歡把頂層組件就堆在一起互相引用，這樣變化的時(shí)候最靈活。

但React組件的Composition結(jié)構(gòu)更符合組件設(shè)計(jì)的原則：組件和組件可以方便的組合起來(lái)實(shí)現(xiàn)更大的組件，而且最重要的，它仍然是只有React定義的只有Prop傳遞的組件。一種自相似性?；蛘呓凶鯟omposability。

簡(jiǎn)單說(shuō)一下React組件的更新過(guò)程；如果一個(gè)組件觀察到變化，或者被子組件調(diào)用了方法，需要更新狀態(tài)，這時(shí)如果變化只影響到自身和某些子組件，它只要直接setState觸發(fā)變化即可，React回調(diào)用它的render方法觸發(fā)一連串的變化，更新是自上至下的，所以比較容易做到更新收斂；如果變化會(huì)影響到組件樹上某個(gè)非子組件的變化，那么應(yīng)該通過(guò)上面?zhèn)鬟f下來(lái)的Bound方法觸發(fā)更高層的組件先做狀態(tài)遷移。這個(gè)設(shè)計(jì)會(huì)導(dǎo)致在狀態(tài)設(shè)計(jì)上出現(xiàn)mediator模式，anyway，這也是常見模式和基本功了。

這里需要強(qiáng)調(diào)的是，理論上這種更新是同步的，雖然React因?yàn)樾蕟栴}做了其他的工作，它的VDOM渲染實(shí)際上是有Batch和異步的，細(xì)節(jié)不說(shuō)了。

那么如果我們不說(shuō)前端，如果寫后端，或者寫系統(tǒng)應(yīng)用，用React的這個(gè)模式構(gòu)建全部組件樹可行嗎？答案是不，也不必要。

這一節(jié)的題目叫做混亂的組件通訊，我們來(lái)仔細(xì)掰扯一下細(xì)節(jié)，因?yàn)榻M件模型雖然很常說(shuō)但是對(duì)通訊過(guò)程沒有約定。

第一個(gè)登場(chǎng)的是function call。

function call不管是同步的還是異步的，它沒有區(qū)分（1）它是否改變了被調(diào)用對(duì)象的狀態(tài)（2）它是否需要返回值。如果它不需要返回值，它就和emit了一個(gè)event沒什么分別。如果它需要一個(gè)返回值，那么調(diào)用者是user角色，被調(diào)用者是provider角色，如果被調(diào)用者的狀態(tài)發(fā)生了變化，這相當(dāng)于crud里的cud，否則是read。

理解了對(duì)function call的分類方式，那么event和message passing也就好理解了。message和function call一樣是模棱兩可的。在Sequence Diagram里，有去必然有回的message被稱為synchronous message，有去無(wú)回的叫做asynchrnous；但是我們避免這個(gè)術(shù)語(yǔ)，和我們?cè)贘S里說(shuō)的不是一回事。但是這個(gè)分類方式是對(duì)的。

相比之下只有event很純粹，它就是有去無(wú)回的。

OK，你看我們的分類方法非常簡(jiǎn)單，就是單向的或者有去有回的。但是內(nèi)在的故事不簡(jiǎn)單。

單向的event，它有可能trigger一個(gè)模型內(nèi)的state或者resource變化（后面統(tǒng)稱為State）。

雙向的通訊，是一種承諾，即使是失敗或錯(cuò)誤也要有返回，我們稱之為IO。注意這個(gè)定義是我自己發(fā)明的，它僅僅表示雙向通訊。

雙向通訊難道就不會(huì)trigger模型內(nèi)的state變化嗎？這當(dāng)然是非?？赡艿摹５菃栴}的關(guān)鍵點(diǎn)就在這里：

對(duì)于一個(gè)提供IO服務(wù)也可能因?yàn)镮O改變其內(nèi)部狀態(tài)的模塊，你是否在代碼層面上把IO和State分離了呢？

我們專注于說(shuō)JavaScript的事件模型；如果你把模塊寫成狀態(tài)機(jī)，模塊接收到的event會(huì)race嗎？當(dāng)然不會(huì)。IO呢？很可能。并發(fā)的本質(zhì)就是IO的并發(fā)，event在單線程的事件模型下沒有并發(fā)的概念。

那么這里就有一個(gè)特別簡(jiǎn)單的建模方式，你可以腦補(bǔ)一個(gè)雞蛋三明治。

三明治兩邊的面包（其實(shí)只有一邊有面包的邏輯也是一樣的），可以看作一個(gè)是向外提供的IO服務(wù)，另一個(gè)是自己需要使用的IO服務(wù)；而中間的雞蛋，是這個(gè)模塊的State，全部State，狀態(tài)機(jī)。

進(jìn)來(lái)的IO如果有資源沖突，可以排隊(duì)；出去的IO如果有返回結(jié)果，返回結(jié)果要當(dāng)作一個(gè)Event來(lái)處理。如果某些Event導(dǎo)致當(dāng)前正在服務(wù)或者排隊(duì)的IO請(qǐng)求失敗，進(jìn)來(lái)的IO請(qǐng)求隊(duì)列清空，全部返回錯(cuò)誤；如果對(duì)象出現(xiàn)生命周期結(jié)束，其發(fā)出的和服務(wù)的IO都要清空，返回失敗或者abort。你看這超級(jí)容易，就是callback隊(duì)列和handle隊(duì)列而已。

我們把中間這層雞蛋，稱為該模塊的模型（model），它封裝了共享資源，實(shí)現(xiàn)了內(nèi)部和外部狀態(tài)。

在這個(gè)模型上前端和后端有沒有區(qū)別呢？還是有的，雖然兩者都可以看作在對(duì)外提供服務(wù)，一個(gè)是服務(wù)機(jī)器另一個(gè)是服務(wù)人。后端的服務(wù)在對(duì)外提供服務(wù)的那層面包上，前端呢，前端都是Event進(jìn)來(lái)的。

在級(jí)聯(lián)這個(gè)問題上，React的組件模型顯示出了它的簡(jiǎn)單抽象的威力。如果我們能夠把所有模塊的雞蛋部分，象React組件那樣級(jí)聯(lián)起來(lái)：

React的框架的render過(guò)程要自己手寫，而且也不大現(xiàn)實(shí)搞成functional風(fēng)格的，只要遵循其自上至下的更新邏輯即可。

React的依賴性全注入的組件形式是非常誘人的，但是在設(shè)計(jì)變更時(shí)要修改mediator在組件樹上的所在位置也有些惱人。這里會(huì)有一些比較tricky的寫法，但是好消息是對(duì)大多數(shù)應(yīng)用而言，其實(shí)粗粒度的組件數(shù)量還沒有一個(gè)React寫的網(wǎng)頁(yè)里的組件數(shù)量多，所以這件事情也不見得要做到極致去，組件數(shù)量不多的時(shí)候Pub/Sub工作的也很好。但是對(duì)于明確的Leaf Node組件，這樣寫是推薦的。

同步更新。能全部組件同步更新雞蛋層是非常值得追求的目標(biāo)。因?yàn)樗屇愕哪Ｐ途哂幸粋€(gè)全局的顯式狀態(tài)設(shè)計(jì)，包含組件相關(guān)的數(shù)據(jù)完整性定義；如果到處是異步狀態(tài)更新，這個(gè)設(shè)計(jì)本身就有麻煩，其邏輯完備性不容易檢驗(yàn)，狀態(tài)機(jī)很容易根據(jù)State/Event組合排查設(shè)計(jì)完備性和合理性，而同步更新是消滅態(tài)空間爆炸的利器，否則狀態(tài)之間要排列組合了。

JavaScript是Event Model。Event Model編程的核心就是用狀態(tài)建模，狀態(tài)同步更新容易保證數(shù)據(jù)完整性。建模的開始是看有那些共享資源需要封裝，把組件一個(gè)一個(gè)寫出來(lái)，然后組合起來(lái)。

過(guò)程在這里是二等公民，它主要致力于上面說(shuō)的面包層的IO處理。從這個(gè)意義上說(shuō)，callback還是promise還是async根本不是重點(diǎn)，沒有什么值得爭(zhēng)執(zhí)的，哪個(gè)合適用哪個(gè)。在狀態(tài)建模之下，IO過(guò)程都被碎片化了，試圖用長(zhǎng)途奔襲的方式串聯(lián)大量IO操作很難保障設(shè)計(jì)正確性，光寫出來(lái)能跑幾次成功測(cè)試的代碼是沒意義的，從這個(gè)意義上說(shuō)我不贊同那些偽線程框架。

事務(wù)鎖的問題不是這篇討論的重點(diǎn)。事件模型下用狀態(tài)機(jī)和IO排隊(duì)解決沖突是第一方法，90%以上用這個(gè)方法；剩下10%是用opportunistic lock的方式一次性commit多個(gè)數(shù)據(jù)更新狀態(tài)，這個(gè)也很容易，但需要注意讀入的數(shù)據(jù)是盡量同步的（有時(shí)這無(wú)法保證，但應(yīng)該去detect非法組合和重試）。

理想的事件模型應(yīng)該是計(jì)算不消耗時(shí)間的；實(shí)際上這當(dāng)然不可能。所以主進(jìn)程的主要目的是維護(hù)全局狀態(tài)層，即所有的雞蛋；文件和網(wǎng)絡(luò)IO操作Node大多做得很好，需要算力的任務(wù)要用Cluster/Worker了，這是Node的短板，只是要求不高的情況下可用。

如果你的后端或者系統(tǒng)應(yīng)用是非常stateful的，包括文件持久化的資源，node是很好的選擇；如果只是對(duì)稱的無(wú)態(tài)邏輯，資源都在數(shù)據(jù)庫(kù)里，node沒什么意義；如果算力要求高，數(shù)據(jù)集也大，不適合在進(jìn)程間拋來(lái)拋去，千萬(wàn)別用node，go/java/c++都是好得多的選擇。

我基本沒有Rx的開發(fā)經(jīng)驗(yàn)，只是看了半本書。

上面說(shuō)的全部文字，都可以看作是基于事件模型的reactive編程；但是rx框架是另一個(gè)故事，它沒有事件模型假設(shè)，有很多語(yǔ)言實(shí)現(xiàn)，而且它考慮的問題不是一個(gè)應(yīng)用級(jí)的，是分布式系統(tǒng)級(jí)的。

但rx是不是一個(gè)好的選擇呢？比如說(shuō)只用于數(shù)據(jù)層？

有可能。但是它用于組件層的話，它有幾個(gè)問題：

1，它沒約定單向，這個(gè)只能自己來(lái)；
2，它需要顯式觀察，即subscribe，個(gè)人認(rèn)為這不如React的注入機(jī)制，后者真正讓組件象樂高積木一樣容易組合的，沒有外部需求的組件才是真正的組件，才可能隨意拆裝使用；

所以我覺得它寫在組件內(nèi)觀察被注入進(jìn)來(lái)的狀態(tài)變化可能更合適，當(dāng)然用于密集的異步IO更新的數(shù)據(jù)集是肯定沒問題的。

把關(guān)鍵點(diǎn)陳列一下，該說(shuō)的前面都說(shuō)過(guò)了。

依賴性注入的組件

狀態(tài)機(jī)和資源建模

狀態(tài)或資源變化即事件，不要額外發(fā)明語(yǔ)義了

理解State和IO的區(qū)別

全局級(jí)聯(lián)的狀態(tài)更新，同步！

～～～～～～～～～～～～～～～～

題外話：

最近在重構(gòu)一個(gè)中等規(guī)模項(xiàng)目，在組件模型上想了很多；但是React的原作者們并沒有特別的覺得他們的設(shè)計(jì)是unusual的。Jordan Walke的大部分視頻都在談react如何使用。

但在我來(lái)看，或者從后端或者系統(tǒng)程序的角度看，react的組件模型在使用上真正符合了組件的定義：無(wú)外部依賴，這一點(diǎn)比node里的module們r(jià)equire來(lái)require去高明太多。