Why React？

做者：BrianLi （部門同事李老師，口頭受權發佈內部react佈道資料）

沒法用語言準確表達思惟時，就用公式；一個不行，那就兩個

—— 李老師

本文假設讀者已瞭解react的基本概念，並有少許react開發實踐。若是沒有，請先閱讀
http://www.ruanyifeng.com/blog/2015/03/react.html

當前咱們如何開發業務？

備註：微信不支持公式，因此我這邊截圖。
補充一下f表示一次用m生成v的渲染方法
g是界面發生交互時，對m作修改的方法

當前業務模塊之間如何通訊？

1. 回調模式：callback

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

3. 僞總線模式：fcContextChange

三種模式沒有本質區別：

1. 回調模式，一次建立一條通訊鏈路，此鏈路工做時不與其餘鏈路發生干擾。
   

2. 觀察者模式，一次建立多條通訊鏈路，每條鏈路工做時與其餘鏈路發生干擾。
   

3. 僞總線模式，是一種特殊的觀察者模式，信息的發出者是一個固定的模塊。

在目前系統中，只存在兄弟通訊和父子通訊，不存在跨樹通訊，即孩子不能跟叔叔直接通訊。若是要跟叔叔通訊，必須藉助祖先中轉。

如今開始簡化模型：

1. 假設系統中模塊之間的鏈路能雙向通訊，這樣能夠將有向鏈路換成無向鏈路；

2. 假設任意兩個模塊之間均可以存在鏈路，但只容許存在一條鏈路，這樣以前不一樣的鏈路類型降低成單條鏈路的一個參數，而且將祖先中轉縮短成直接通訊；

3. 把系統中的模塊看做頂點，模塊間通訊鏈路看做邊，則系統變成了無向圖。
   

這是模型簡化後的鏈路數量，而目前咱們系統中的鏈路數比這多得多，由於咱們容許節點間有多條鏈路，並且鏈路是單向通訊的。

咱們開發業務時很大一部分工做量就是建立各類通訊鏈路，隨着系統複雜性不斷增長，圖愈來愈複雜，代碼邏輯就沒人能看懂了，由於數據在系統中的流動是沒有規律的。

React基本原則2：在React中，數據流是單向的。數據老是自頂而下流動，內部不容許出現反向數據流。React簡化通訊的方法至關粗暴，既然管理很差通訊，那麼幹脆禁止通訊。

如何用React知足咱們的通訊需求？React的作法是：

1. 把整個應用抽象成一個數據集;

2. 每一個子模塊使用數據集的一部分作渲染，涉及渲染的數據經過props向下傳遞；

3. 每一個子模塊均可以直接修改最頂層的數據集。

如今，系統中通訊鏈路條數變成了n，系統複雜度徹底在咱們掌控之中。固然這樣作也是有弊端的，全部數據放在一個model中，這個model必然很龐大，維護起來須要必定技巧，相應地出現了flux和redux等框架專門用於管理model，目前咱們沒有引入，準備使用ER.model，增強命名規範，來臨時解決這一問題。

最關鍵，上圖綠色鏈路的建立過程是半自動化的，只須要把修改model的回調函數mode.dispatch經過props一層層傳遞下去。固然，綠色鏈路的建立能夠利用react.context作成全自動，但react官方對context的使用有疑慮，而且API在未來可能會修改，因此暫時沒有引入。

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.

當前咱們如何測試ui和業務模塊？

答案是測試基本靠手。怎麼測試交互？目前有基於web driver的OneUX SDK方案。這個方案用腳本模仿了鼠標鍵盤操做，容許咱們實現自動化測試。
但問題不在這裏，而是工做量的問題。模擬操做的方式，歸根究竟是QA把手動測試過程用腳本記錄下來。若是測試一次性經過，手動測試和寫腳本的工做量是一致的。

在React中，自動化測試變得很是簡單。還記得React基本原則1麼？props + state是渲染界面view的惟一依據。所以，用戶在頁面的交互行爲，最終都轉化成props或state的變化。

我的博客

http://tangguangyao.github.io/

微信公衆號