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/

微信公众号