传统的前端MVC模式存在一个很严重的问题，就是当项目逻辑越来越复杂时，数据流动很容易变得混乱，而这种问题的解决方案就是只存放一个渲染函数于Controller 中，每次更新重渲染页面，但重渲染容易带来严重的性能与用户体验问题。因此 Facebook提出Flux来解决这个问题。

1. 什么是Flux?

Flux是一套基于dispatcher的前端应用架构模式，它由3大部分组成——dispatcher、store 和 view，其中dispatcher负责分发事件；store 负责保存数据，同时响应事件并更新数据；view负责订阅 store 中的数据，并使用这些数据渲染相应的页面。
Flux的简化流程图如图所示:

Flux流程图.png

1. dispatcher 与 action
   dispatcher 是 Flux 中最核心的概念，其主要的API有两个，.register(callback)和.dispatch(action)，register方法用来注册一个监听器，而 dispatch 方法用来分发一个 action。
2. store
   store 负责保存数据，并定义修改数据的逻辑。在 Flux 中，store 对外只暴露 getter（读取器）而不暴露 setter（设置器），因此只能读取 store 中的数据而不能进行任何修改。
3. controller-view
   主要进行 store 与 React 组件（即 view 层）之间的绑定，定义数据更新及传递的方式。它会调用 store 暴露的getter 获取存储其中的数据并设置为自己的 state，在render 时以 props 的形式传给自己的子组件
4. view
   如果view层操作需要修改数据，则必须使用 dispatcher 分发一个 action，这也是在Flux中唯一修改数据的方式。
5. actionCreator
   actionCreator是当分发 action 的时候代码有冗余的情况下使用的。将可以重用的action部分代码封装起来，每次修改action只需要在actionCreator 中进行修改即可。

2. 为什么选择Flux模式?

flux的核心思想是数据和逻辑永远单向流动，其模型图如图所示。

Flux模型图

那么Flux是如何解决MVC模式存在的不足呢？主要有两点：

1. Flux是如何实现单向数据流的呢？ Flux 的 dispatcher 定义了严格的规则来限定我们对数据的修改操作。同时，store 中不能暴露 setter 的设定也强化了数据修改的纯洁性，保证了 store 的数据确定应用唯一的状态。
2. Flux中的view每次重渲染的是Virtual DOM，并由PureRender 保障从重渲染到局部渲染的转换，因此不会影响页面的性能优化。