经过前面一系列章节的学习，我们明白了 Flux 的设计思想和工作原理，是不是觉得 Flux 原来如此简单呀！

Facebook 提供的 flux 依赖包中，只有 dispatcher 一个核心概念。当然，随着后续的迭代，也增加了一些方便函数编程的 utils 方法和语法糖。

还是那句话：Flux 不是一个具体的框架或者类库，而更像是一种设计模式。

核心思想

这一系列章节中，我们不断的在强调：在 Flux 中，组件相关的所有数据状态都是集中式存储的，如果需要改变其中的数据状态，我们必须通过 dispatcher 统一来分配 action，而 action 是一个普通的 JavaScript 对象，描述了数据状态的变化，Store 里面的数据状态变化后，会触发 change 事件，在 controller-view 那边就会响应事先已经绑定的 change 监听事件。

在上面的工作流中，Flux 做到了很好的状态中心化的控制，可以使 view 保持高度的简洁，不用关注太多的逻辑，只需要关心传入的数据即可。中心化控制了所有的数据，发生了问题或出现了 bug 也方便查找。和 MVC 架构模式下数据和逻辑的改动可能引起的混乱和多个不同源头，Flux 架构追查问题的优势就体现出来了。

另外，Flux 提出了 action 的概念用来描述状态的变化（无论是由用户主动触发还是服务端发起的或者应用本身的行为）。而对于开发者来说，action 就是一个动作，提高了系统的抽象度。和 MVC 架构下管理不同的触发方式，Flux 显得优雅了许多。

问题和不足

任何事物都有两面性，对于技术也是一样的。没有一种架构模式是完美的存在，每种架构模式都有其存在的价值。Flux 也是这样的。Flux 最大的问题就是冗余代码太多，对于每个应用都需要手动创建一个 dispatcher 实例。

由于 Flux 主要是给开发者提供了一种思想，其设计约定很大程度上是很松散的，因此在社区中有很多关于 Flux 思想的不同实现，其中以 Redux 和 Refluxjs 最为出名。