dispatch作用 react_在 React 中处理数据流问题的一些思考

背景

相信大家在项目开发中，在页面较复杂的情况下，往往会遇到一个问题，就是在页面组件之间通信会非常困难。

比如说一个商品列表和一个已添加商品列表：

假如这两个列表是独立的两个组件，它们会共享一个数据 “被选中的商品”，在商品列表选中一个商品，会影响已添加商品列表，在已添加列表中删除一个商品，同样会影响商品列表的选中状态。

它们两个是兄弟组件，在没有数据流框架的帮助下，在组件内数据有变化的时候，只能通过父组件传输数据，往往会有 onSelectedDataChange 这种函数出现，在这种情况下，还尚且能忍受，如果组件嵌套较深的话，那痛苦可以想象一下，所以才有解决数据流的各种框架的出现。

本质分析

我们知道 React 是 MVC 里的 V，并且是数据驱动视图的，简单来说，就是数据 => 视图，视图是基于数据的渲染结果：

V = f(M)

数据有更新的时候，在进入渲染之前，会先生成 Virtual DOM，前后进行对比，有变化才进行真正的渲染。

V + ΔV = f(M + ΔM)

数据驱动视图变化有两种方式，一种是 setState，改变页面的 state，一种是触发 props 的变化。

我们知道数据是不会自己改变，那么肯定是有“外力”去推动，往往是远程请求数据回来或者是 UI 上的交互行为，我们统称这些行为叫 action：

ΔM = perform(action)

每一个 action 都会去改变数据，那么视图得到的数据（state）就是所有 action 叠加起来的变更，

state = actions.reduce(reducer, initState)

所以真实的场景会出现如下或更复杂的情况：

问题就出在，更新数据比较麻烦，混乱，每次要更新数据，都要一层层传递，在页面交互复杂的情况下，无法对数据进行管控。

有没有一种方式，有个集中的地方去管理数据，集中处理数据的接收，修改和分发？答案显然是有的，数据流框架就是做这个事情，熟悉 Redux 的话，就知道其实上面讲的就是 Redux 的核心理念，它和 React 的数据驱动原理是相匹配的。

数据流框架

Redux

数据流框架目前占主要地位的还是 Redux，它提供一个全局 Store 处理应用数据的接收，修改和分发。