摘要：观察者模式，一次创建多条通信链路，每条链路工作时与其他链路发生干扰。在目前系统中，只存在兄弟通信和父子通信，不存在跨树通信，即孩子不能跟叔叔直接通信。模拟操作的方式，归根到底是把手动测试过程用脚本记录下来。
作者：BrianLi （部门同事李老师，口头授权发布内部react布道资料）
无法用语言准确表达思维时，就用公式；一个不行，那就两个
—— 李老师
本文假设读者已了解react的基本概念，并有少量react开发实践。如果没有，请先阅读
http://www.ruanyifeng.com/blog/2015/03/react.html
当前业务模块之间如何通信？备注：微信不支持公式，所以我这边截图。
补充一下f表示一次用m生成v的渲染方法
g是界面发生交互时，对m做修改的方法
回调模式：callback
观察者模式：on / fire (addEventListener / removeEventListener)
伪总线模式：fcContextChange
三种模式没有本质区别：
回调模式，一次创建一条通信链路，此链路工作时不与其他链路发生干扰。
观察者模式，一次创建多条通信链路，每条链路工作时与其他链路发生干扰。
伪总线模式，是一种特殊的观察者模式，信息的发出者是一个固定的模块。
在目前系统中，只存在兄弟通信和父子通信，不存在跨树通信，即孩子不能跟叔叔直接通信。如果要跟叔叔通信，必须借助祖先中转。
现在开始简化模型：
假设系统中模块之间的链路能双向通信，这样可以将有向链路换成无向链路；
假设任意两个模块之间都可以存在链路，但只允许存在一条链路，这样之前不同的链路类型下降成单条链路的一个参数，并且将祖先中转缩短成直接通信；
把系统中的模块看作顶点，模块间通信链路看作边，则系统变成了无向图。
这是模型简化后的链路数量，而目前我们系统中的链路数比这多得多，因为我们允许节点间有多条链路，而且链路是单向通信的。
我们开发业务时很大一部分工作量就是创建各种通信链路，随着系统复杂性不断增加，图越来越复杂，代码逻辑就没人能看懂了，因为数据在系统中的流动是没有规律的。
React基本原则2：在React中，数据流是单向的。数据总是自顶而下流动，内部不允许出现反向数据流。React简化通信的方法相当粗暴，既然管理不好通信，那么干脆禁止通信。
如何用React满足我们的通信需求？React的做法是：
把整个应用抽象成一个数据集;
每个子模块使用数据集的一部分做渲染，涉及渲染的数据通过props向下传递；
每个子模块都可以直接修改最顶层的数据集。
现在，系统中通信链路条数变成了n，系统复杂度完全在我们掌控之中。当然这样做也是有弊端的，所有数据放在一个model中，这个model必然很庞大，维护起来需要一定技巧，相应地出现了flux和redux等框架专门用于管理model，目前我们没有引入，准备使用ER.model，加强命名规范，来临时解决这一问题。
最关键，上图绿色链路的创建过程是半自动化的，只需要把修改model的回调函数mode.dispatch通过props一层层传递下去。当然，绿色链路的创建可以利用react.context做成全自动，但react官方对context的使用有疑虑，并且API在将来可能会修改，所以暂时没有引入。
当前我们如何测试ui和业务模块？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.
答案是测试基本靠手。怎么测试交互？目前有基于web driver的OneUX SDK方案。这个方案用脚本模仿了鼠标键盘操作，允许我们实现自动化测试。
但问题不在这里，而是工作量的问题。模拟操作的方式，归根到底是QA把手动测试过程用脚本记录下来。如果测试一次性通过，手动测试和写脚本的工作量是一致的。
在React中，自动化测试变得非常简单。还记得React基本原则1么？props + state是渲染界面view的唯一依据。因此，用户在页面的交互行为，最终都转化成props或state的变化。
个人博客http://tangguangyao.github.io/
微信公众号文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/78863.html
摘要：官方说法注本人英语二十六级是和用来创建用户界面的库。很多人将认为是中的。怎么说呢现在的自己就是个跟风狗啊，什么流行先学习了再说，再看看能不能应用在具体项目上。暂时先停下的学习，坐等。不过学习的脚步还是跟不上潮流的发展速度啊。 Why React? 官方说法 注：本人英语二十六级 React是Facebook和Instagram用来创建用户界面的JavaScript库。很多...
摘要：如何修复既然是不需要渲染，那就要阻止它的渲染。我个人觉得，在实际中，用跟两个工具已经可以很好帮我们判断哪部分不需要重新渲染，帮助我们做出优化。 背景 上一篇文章的结尾http://imweb.io/topic/5985cc4...我们说到，也许，不是所有的节点都需要重新渲染，对于那些不需要渲染的节点，我们如何找到它们并做优化呢？ 本篇文章来具体解答这个问题。 应用分析 首先，先看这个应...
摘要：三性能优化处理做工具类的项目，性能是非常大的挑战，我总结了以下几个常见的性能优化点数据缓存。防抖，节流，事件委托内存释放。 内容大纲： 1、功能介绍 2、技术架构 3、性能优化 4、细节分享 5、开源说明 一、项目功能介绍 很久没写过技术类的文章了，这次给大家分享一个近期的项目，采用react+mobx+jquery构建的大型工具类项目。查看项目网址。 如果用过易企秀，maka或者...
摘要：三性能优化处理做工具类的项目，性能是非常大的挑战，我总结了以下几个常见的性能优化点数据缓存。防抖，节流，事件委托内存释放。 内容大纲： 1、功能介绍 2、技术架构 3、性能优化 4、细节分享 5、开源说明 一、项目功能介绍 很久没写过技术类的文章了，这次给大家分享一个近期的项目，采用react+mobx+jquery构建的大型工具类项目。查看项目网址。 如果用过易企秀，maka或者...
阅读 2207·2021-11-17 09:33
阅读 2753·2021-11-12 10:36
阅读 3366·2021-09-27 13:47
阅读 855·2021-09-22 15:10
阅读 3453·2021-09-09 11:51
阅读 1348·2021-08-25 09:38
阅读 2733·2019-08-30 15:55
阅读 2573·2019-08-30 15:53
