前言

相信使用过 React + Rdux 的人对下面这张图都不陌生

redux.jpeg

那么，我来换种方式解释下，如下图：

redux2.png

当用户有交互行为时，通过 action 改变 M1 到 M2，即：用户对 M1 的页面做了一个操作（action）让 M1 产生了改变 M'，这时 M1 变成了 M2，对应的页面也由页面一刷新成了 M2 对应的页面二；同理，M2 通过交互变成了 M3，页面也会刷新成 M3 对应的页面三。

这个过程的核心就是 数据驱动 （页面的行为使得数据改变，数据渲染出数据改变后相应的页面）

数据驱动的价值

对于下面这个交互复杂的页面：

一个交互复杂的页面.png

首先用传统的方式来处理它的页面交互，此时页面会变成这样：

传统方式.png

显而易见，**整个模块的通信已经成了蜘蛛网，而且每一条关系线都需要开发者来维护，这不仅影响开发效率，同时不好维护，容易引发各种 bug **。

让我们来尝试用数据驱动的思想来画一次这个页面的交互图：

使用数据驱动思想.png

页面之间每个模块，不用关系父子模块之间的关系，每个独立的模块都是由一个全局的 model 决定。

解析：
当 B2 改变时，它会修改 model 中对应的数据，然后 A2 的业务模块接收到变化后的数据，舒心页面。

这种交互，将每一个模块的改变，全部交给 model 处理。最大的优势在于：当交互逻辑不断增加时，这个关系链依然不会增加，因为模块之和 model 里面的数据相关联。

也可以理解为，页面上的所有的操作都是对数据的操作，每个模块只需要监听自己关注的数据改变即可。

关注点：

ps：基于以上缺陷，由于这方面的代码，写的还是太少，并没体会到。在未来应该会有感触。

React 页面渲染可以理解为，由许多照片一帧一帧构成的视频，每个历史状态都是一个 state。也正是由于这些 state 的变化，而引起了页面的变化。

从一开始我们写页面的时候，老师都会先让我们画原型图、组件图，然后再开始写组件。

其实，我们写完组件加逻辑的时候，不妨全局思考一下，如何构造这个数据结构，页面中每个状态又又什么联系呢？

其实，以上图片来源 copy，思考完全是由于放假前林老师布置的一个作业 301-react-form 而引发的，它的出栈篇第一条就是：谈谈你对数据驱动的理解。不知道，我这样的理解能否达到出栈的要求。也许还要在这个栈待很久......