前言
相信使用过 React + Rdux 的人对下面这张图都不陌生
那么，我来换种方式解释下，如下图：
当用户有交互行为时，通过 action 改变 M1 到 M2，即：用户对 M1 的页面做了一个操作（action）让 M1 产生了改变 M'，这时 M1 变成了 M2，对应的页面也由页面一刷新成了 M2 对应的页面二；同理，M2 通过交互变成了 M3，页面也会刷新成 M3 对应的页面三。
这个过程的核心就是 数据驱动 （页面的行为使得数据改变，数据渲染出数据改变后相应的页面）
数据驱动的价值
对于下面这个交互复杂的页面：
首先用传统的方式来处理它的页面交互，此时页面会变成这样：
显而易见，**整个模块的通信已经成了蜘蛛网，而且每一条关系线都需要开发者来维护，这不仅影响开发效率，同时不好维护，容易引发各种 bug **。
让我们来尝试用数据驱动的思想来画一次这个页面的交互图：
页面之间每个模块，不用关系父子模块之间的关系，每个独立的模块都是由一个全局的 model 决定。
解析：
当 B2 改变时，它会修改 model 中对应的数据，然后 A2 的业务模块接收到变化后的数据，舒心页面。
这种交互，将每一个模块的改变，全部交给 model 处理。最大的优势在于：当交互逻辑不断增加时，这个关系链依然不会增加，因为模块之和 model 里面的数据相关联。
也可以理解为，页面上的所有的操作都是对数据的操作，每个模块只需要监听自己关注的数据改变即可。
关注点：
- 数据结构的处理。
- 数据决定了整个页面的展示。
- 模块和数据中对应的关系。
数据驱动的缺陷
- 初期的数据结构设计在未来会是一个定时炸弹。
- 数据驱动下，数据的重复和同步是一个坑。
- 对应某些具体的模块，单向数据流不是万灵药，整体架构单向数据驱动，具体模块可以根据场景选择最合适的。
ps：基于以上缺陷，由于这方面的代码，写的还是太少，并没体会到。在未来应该会有感触。
后续
React 页面渲染可以理解为，由许多照片一帧一帧构成的视频，每个历史状态都是一个 state。也正是由于这些 state 的变化，而引起了页面的变化。
从一开始我们写页面的时候，老师都会先让我们画原型图、组件图，然后再开始写组件。
其实，我们写完组件加逻辑的时候，不妨全局思考一下，如何构造这个数据结构，页面中每个状态又又什么联系呢？
其实，以上图片来源 copy，思考完全是由于放假前林老师布置的一个作业 301-react-form 而引发的，它的出栈篇第一条就是：谈谈你对数据驱动的理解。不知道，我这样的理解能否达到出栈的要求。也许还要在这个栈待很久......
