作者：BrianLi （部門同事李老師，口頭授權(quán)發(fā)布內(nèi)部react布道資料）

無法用語(yǔ)言準(zhǔn)確表達(dá)思維時(shí)，就用公式；一個(gè)不行，那就兩個(gè)

—— 李老師

本文假設(shè)讀者已了解react的基本概念，并有少量react開發(fā)實(shí)踐。如果沒有，請(qǐng)先閱讀
http://www.ruanyifeng.com/blog/2015/03/react.html

當(dāng)前我們?nèi)绾伍_發(fā)業(yè)務(wù)？

備注：微信不支持公式，所以我這邊截圖。
補(bǔ)充一下f表示一次用m生成v的渲染方法
g是界面發(fā)生交互時(shí)，對(duì)m做修改的方法

當(dāng)前業(yè)務(wù)模塊之間如何通信？

回調(diào)模式：callback

觀察者模式：on / fire (addEventListener / removeEventListener)

偽總線模式：fcContextChange

三種模式?jīng)]有本質(zhì)區(qū)別：

回調(diào)模式，一次創(chuàng)建一條通信鏈路，此鏈路工作時(shí)不與其他鏈路發(fā)生干擾。

觀察者模式，一次創(chuàng)建多條通信鏈路，每條鏈路工作時(shí)與其他鏈路發(fā)生干擾。

偽總線模式，是一種特殊的觀察者模式，信息的發(fā)出者是一個(gè)固定的模塊。

在目前系統(tǒng)中，只存在兄弟通信和父子通信，不存在跨樹通信，即孩子不能跟叔叔直接通信。如果要跟叔叔通信，必須借助祖先中轉(zhuǎn)。

現(xiàn)在開始簡(jiǎn)化模型：

假設(shè)系統(tǒng)中模塊之間的鏈路能雙向通信，這樣可以將有向鏈路換成無向鏈路；

假設(shè)任意兩個(gè)模塊之間都可以存在鏈路，但只允許存在一條鏈路，這樣之前不同的鏈路類型下降成單條鏈路的一個(gè)參數(shù)，并且將祖先中轉(zhuǎn)縮短成直接通信；

把系統(tǒng)中的模塊看作頂點(diǎn)，模塊間通信鏈路看作邊，則系統(tǒng)變成了無向圖。

這是模型簡(jiǎn)化后的鏈路數(shù)量，而目前我們系統(tǒng)中的鏈路數(shù)比這多得多，因?yàn)槲覀冊(cè)试S節(jié)點(diǎn)間有多條鏈路，而且鏈路是單向通信的。

我們開發(fā)業(yè)務(wù)時(shí)很大一部分工作量就是創(chuàng)建各種通信鏈路，隨著系統(tǒng)復(fù)雜性不斷增加，圖越來越復(fù)雜，代碼邏輯就沒人能看懂了，因?yàn)閿?shù)據(jù)在系統(tǒng)中的流動(dòng)是沒有規(guī)律的。

React基本原則2：在React中，數(shù)據(jù)流是單向的。數(shù)據(jù)總是自頂而下流動(dòng)，內(nèi)部不允許出現(xiàn)反向數(shù)據(jù)流。React簡(jiǎn)化通信的方法相當(dāng)粗暴，既然管理不好通信，那么干脆禁止通信。

如何用React滿足我們的通信需求？React的做法是：

把整個(gè)應(yīng)用抽象成一個(gè)數(shù)據(jù)集;

每個(gè)子模塊使用數(shù)據(jù)集的一部分做渲染，涉及渲染的數(shù)據(jù)通過props向下傳遞；

每個(gè)子模塊都可以直接修改最頂層的數(shù)據(jù)集。

現(xiàn)在，系統(tǒng)中通信鏈路條數(shù)變成了n，系統(tǒng)復(fù)雜度完全在我們掌控之中。當(dāng)然這樣做也是有弊端的，所有數(shù)據(jù)放在一個(gè)model中，這個(gè)model必然很龐大，維護(hù)起來需要一定技巧，相應(yīng)地出現(xiàn)了flux和redux等框架專門用于管理model，目前我們沒有引入，準(zhǔn)備使用ER.model，加強(qiáng)命名規(guī)范，來臨時(shí)解決這一問題。

最關(guān)鍵，上圖綠色鏈路的創(chuàng)建過程是半自動(dòng)化的，只需要把修改model的回調(diào)函數(shù)mode.dispatch通過props一層層傳遞下去。當(dāng)然，綠色鏈路的創(chuàng)建可以利用react.context做成全自動(dòng)，但react官方對(duì)context的使用有疑慮，并且API在將來可能會(huì)修改，所以暫時(shí)沒有引入。

Note

Context is an advanced and experimental feature. The API is likely to change in future releases.

Most applications will never need to use context. Especially if you are just getting started with React, you likely do not want to use context. Using context will make your code harder to understand because it makes the data flow less clear. It is similar to using global variables to pass state through your application.

If you have to use context, use it sparingly.

Regardless of whether you're building an application or a library, try to isolate your use of context to a small area and avoid using the context API directly when possible so that it's easier to upgrade when the API changes.

當(dāng)前我們?nèi)绾螠y(cè)試ui和業(yè)務(wù)模塊？

答案是測(cè)試基本靠手。怎么測(cè)試交互？目前有基于web driver的OneUX SDK方案。這個(gè)方案用腳本模仿了鼠標(biāo)鍵盤操作，允許我們實(shí)現(xiàn)自動(dòng)化測(cè)試。
但問題不在這里，而是工作量的問題。模擬操作的方式，歸根到底是QA把手動(dòng)測(cè)試過程用腳本記錄下來。如果測(cè)試一次性通過，手動(dòng)測(cè)試和寫腳本的工作量是一致的。

在React中，自動(dòng)化測(cè)試變得非常簡(jiǎn)單。還記得React基本原則1么？props + state是渲染界面view的唯一依據(jù)。因此，用戶在頁(yè)面的交互行為，最終都轉(zhuǎn)化成props或state的變化。

個(gè)人博客

http://tangguangyao.github.io/

微信公眾號(hào)

總結(jié)

以上是生活随笔為你收集整理的Why React？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。