一句话总结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到了吗？