Flux架构
Redux的设计很大程度上受益于Flux架构思想，可以认为Redux是Flux的一种实现形式(虽然它并不严格遵循Flux的设定)，理解Flux可以从抽象层面把握Redux
Flux并不是一个具体的框架，而是脸书技术团队提出的一种应用架构，这套架构约束的是应用处理数据的模式。在Flux架构中，一个应用将被拆分为四个部分：View(视图层)、Action(动作)、Dispatcher(派发器)、Store(数据层)
- View(视图层)：也就是用户界面，该用户界面可以是以任何形式实现出来的，React中的组件就是一种形式。Flux架构和React之间并不存在耦合关系。
- Action(动作)：也可以理解为视图层发出的“消息”，它会触发应用状态发生改变
- Dispatcher(派发器)：用来把生成的action分发给store
- Store(数据层)：他是存储应用状态的“仓库”，此外还会定义修改状态的逻辑。Store最终的变化会映射到View层
- 注意：所有的箭头都是单向的，这就是Flux架构的特点：单向数据流
- 典型的工作流程：用户与View层交互，生成一个Action，然后Dispatcher将这个Action分发给Store，Store进行相应的状态的修改以及更新，最后呈现在View层
Flux架构解决了什么问题？
Flux的典型特征是单向数据流，其优缺点需要与双向数据流架构做对比
双向数据流最经典的代表是MVC架构： (View => Controller => Model)
- 允许用户通过与View层的交互来触发流程
2. 允许用户直接通过Controller来触发流程
- 但是在实际应用中，为了满足交互的需要，往往会允许view与model之间直接交互，这样就会形成双向数据流。
- 在更为复杂的情况下，单个view会与多个model发生交互，单个model也会与多个view建立联系，这样就会造成“蝴蝶效应”：不知道bug是哪个model引发的，修改一个model影响多个view，修改一个view影响多个model
- 在更为复杂的情况下，单个view会与多个model发生交互，单个model也会与多个view建立联系，这样就会造成“蝴蝶效应”：不知道bug是哪个model引发的，修改一个model影响多个view，修改一个view影响多个model
在这种情况下，使用单项数据流(Flux架构)的好处就体现出来了：
- Flux要求严格的单项数据流，在单向数据流下，状态的变化是可预测的：如果store中的数据发生了变化，那么一定是由Dispatcher派发的Action触发的，这样的关系非常有助于debug以及避免混乱的数据关系。
- 但是Flux并不是完美的：开发者学习成本相对较高、以及较高的代码量
- Flux架构比较适用于复杂的项目，简单的项目完全轮不到Flux登场
