一句话总结flux，以及我们为何需要flux

如果让你用一句话总结一下什么是flux，该怎么说？

官网上有这样的介绍：flux是一种思想，一种框架，是facebook给react。。。

这样的解释对程序员来说，显得过于抽象又不具体了。

阮老师的文章，也将官网的介绍很好的翻译了一遍。读了以后可以了解到flux是由哪些部分组成（store，dispatcher，action，view）。但就算知道了这些，还是没法很好的解答程序员同学们心中的疑惑，flux到底是什么，用来做什么的，为什么用它，用它有什么好处呢？

如果有一本历史书，写了flux诞生的各个事件，也许事情就没那么复杂了。现在没有这本书，我们使用flux的过程，就像是盲人摸象。那么现在，摸了很久，摸了很多次，很全面的摸过这个大象以后，我们来总结一下我们摸到了什么吧。

1.flux是一个数据中间层，用于规范的管理数据，这些数据往往以状态(state)来呈现。

2.flux不是必须的，但当你使用react或vue等组件化的mvvm框架的时候，flux似乎变得特别的顺手起来。

3.越是复杂的业务逻辑、数据处理、数据模板，越是将你快速的送到flux面前。

总结到一句话就是：flux是一个善于对复杂数据模型进行规范管理的中间层，并且它与组件化的mvvm框架有互补作用。

复杂是一个相对的概念。那么复杂到什么地步，我们就需要flux了呢？

来看一个例子：

假定组件化开发程序中，三个不同层级的组件使用了同一个数据对象作为数据模型的一部分。三个组件对共用的数据对象各有操作，又互相影响。

这种情况下有两个比较严重的问题：

1.三个不同组件对数据对象的操作各不相同，操作部分因各个组件环境不同，操作代码将与组件自身的业务代码混在一起。不方便后期维护。

2.换个程序员就很难找齐操作过这部分数据的三个不同位置的组件，以及组件中操作数据的各行代码了。

而使用flux可以统一数据操作接口（action，dispatcher），方便查找操作数据的入口（调用了相同的action/dispatcher），这就解决了上边提出的两点问题，增强了数据的可维护性，可扩展性。

再来看一个例子：

例子叫做状态管理好了：一个组件，要undo，redo，进入不同的历史状态。

用户可以手动构建单独的状态管理器，而flux可以通过store，dispatcher，action轻松的实现对状态数据的管理。从这个角度来看，flux又可以被看做是一个复杂状态管理器，只不过flux不局限于管理组件的状态，而是更深层次的将数据与状态视为一体。从mvvm的角度来看，管理数据也是在管理状态。

so, flux带给我们的是一种面对复杂问题的解决方案，你get到了吗？