目录
1、预备知识
先提出个疑问：我们为什么需要状态管理？
对于SPA应用来说，前端所需要管理的状态越来越多，需要查询、更新、传递的状态也越来越多， 如果让每个组件都存储自身相关的状态，理论上来讲不会影响应用的运行， 但在开发及后续维护阶段，我们将花费大量精力去查询状态的变化过程， 在多组合组件通信或客户端与服务端有较多交互过程中， 我们往往需要去更新、维护并监听每一个组件的状态，在这种情况下， 如果有一种可以对状态做集中管理的地方是不是会更好呢？ 状态管理好比是一个集中在一处的配置箱，当需要更新状态的时候， 我们仅对这个黑箱进行输入，而不用去关心状态是如何分发到每一个组件内部的， 这可以让开发者将精力更好的放在业务逻辑上。
但状态管理并不是必需品，当你的UI层比较简单、没有较多的交互去改变状态的场景下， 使用状态管理方式反倒会让你的项目变的复杂。 例如Redux的发明者Dan Abramov就说过这样一句话： “只有遇到React实在解决不了的问题，你才需要Redux”。
一般来讲，在以下场景下你或许需要使用状态管理机制去维护应用：
- 用户操作较为繁琐，导致组件间需要有状态依赖关系，如根据多筛选条件来控制其他组件的功能。
- 客户端权限较多且有不同的使用方式，如管理层、普通层级等。
- 客户端与服务端有大量交互，例如请求信息实时性要求较高导致需要保证鲜活度。
- 前端数据缓存部分较多，如记录用户对表单的提交前操作、分页控制等。
另外，本篇文章更关注业务模型层的数据流， 业务模型是指所处领域的业务数据、规则、流程的集合。 即使抛开所有展示层，这一层也可以不依赖于展示层而独立运行， 这里要强调一点，Redux之类的状态管理库充当了一个应用的业务模型层， 并不会受限于如React之类的View层。 假如你已经明白了Redux的定位及应用场景的话，我们来对其原理一探究竟。
2、与react结合使用
3、原理
4、数据流向
我们先来看一下一个完整的Redux数据流是怎样的：
