为什么要使用Redux，它解决了什么问题

1.当我们的应用遇到多个组件共享状态时，单向数据流的简洁性很容易被破坏：
2.多个视图依赖于同一状态。来自不同视图的行为需要变更同一状态。
**
把组件的共享状态抽取出来，以一个全局单例模式管理,在这种模式下，我们的组件树构成了一个巨大的“视图”，不管在树的哪个位置，任何组件都能获取状态或者触发行为！

Flux约定，解决此问题：“理解你的应用的状态变化是很困难的”

视图层组件不允许直接修改应用状态，只能触发 action。 应用的状态必须独立出来放到 store 里面统一管理，通过侦听 action 来执行具体的状态操作。 所谓的单向数据流，就是当用户进行操作的时候，会从组件发出一个 action，这个 action 流到 store 里面，触发 store 对状态进行改动，然后 store 又触发组件基于新的状态重新渲染。这样做的好处：

  1. 视图组件变得很薄，只包含了渲染逻辑和触发 action 这两个职责，即所谓 “dumb components”。 [dʌm]
  2. 要理解一个 store 可能发生的状态变化，只需要看它所注册的 actions 回调就可以。
  3. 任何状态的变化都必须通过 action 触发，而 action 又必须通过 dispatcher 走，所以整个应用的每一次状态变化都会从同一个地方流过。 其实 Flux 和传统 MVC 最不一样的就在这里了。 React 在宣传的时候一直强调的一点就是 “理解你的应用的状态变化是很困难的 (managing state changing over time is hard)”， Flux 的意义就在于强制让所有的状态变化都必须留下一笔记录，这样就可以利用这个来做各种 debug 工具、历史回滚等等。

    单向数据流

    所有的 prop 都使得其父子 prop 之间形成了一个单向下行绑定：父级 prop 的更新会向下流动到子组件中，但是反过来则不行。这样会防止从子组件意外改变父级组件的状态，从而导致你的应用的数据流向难以理解。