纸上得来终觉浅，绝知此事要躬行
前言
工作虽然一直用react，但是都是现学现用，花了点时间通读《深入react技术栈》，学习笔记略作整理
传统MVC缺点，在项目越来越大，逻辑越来越复杂时，数据流动变的越来越混乱。
Flux 的解决方案
Flux 的核心思想就是数据和逻辑永远单向流动。
flux数据模型
基本概念
一个 Flux 应用由 3 大部分组成——dispatcher、store 和 view，其中
- dispatcher 负责分发事件；
- store 负责保存数据，同时响应事件并更新数据；
- view 负责订阅 store 中的数据，并使用这些数据
渲染相应的页面
核心思想
- Flux 的中心化控制。让所有的请求与改变都只能通过 action 发出，统一由 dispatcher 来分配。
- View 可以保持高度简洁，它不需要关心太多的逻辑，只需要关心传入的数据；
- 中心化还控制了所有数据，发生问题时可以方便查询。比起 MVC 架构下数据或逻
辑的改动可能来自多个完全不同的源头，Flux 架构追查问题的复杂度和困难度显然要小得多。
- Flux 把 action 做了统一归纳，提高了系统抽象程度。不论 action 是由用户触发的，从服务端发起的，还是应用本身的行为，对于我们而言，它都只是一个动作而已。与 MVC 架构下
不同的触发方式管理混乱相比，Flux 要优雅许多。flux不足
- Flux 的冗余代码太多，Flux 源码中几乎只有 dispatcher的实现，但是在每个应用中都需要手动创建一个 dispatcher 的示例
- Flux 给开发者提供的还是它的思想。Flux 在很大程度上是一种很松散的设计约定，不同的开发者对 Flux 都会有自己的理解
redux
基本概念
Redux 参考了 Flux 的设计，但是对 Flux 许多冗余的部分（如 dispatcher）做了
简化，同时将 Elm 语言中函数式编程的思想融合其中。
Redux 三大原则
- 单一数据源。
- 整个应用状态都保存在一个对象中，可以提取出整个应用的状态进行持久化（比如实现一个针对整个应用的即时保存功能）
- 也为服务端渲染提供了可能。
- 状态是只读的。
- 在 Redux 中不会定义一个 store，而是定义一个 reducer，它的功能是根据当前触发的 action 对当前应用的状态（state）进行迭代，这里并没有直接修改应用的状态，而是返回了一份全新的状态。
- Redux 提供的 createStore 方法会根据reducer 生成 store。
- 最后，我们可以利用 store. dispatch方法来达到修改状态的目的。
- 状态修改均由纯函数完成。
