Flux, Reflux和Redux它们都是用于管理数据流转的。那么它们为什么会出现，各自又解决了什么问题呢？
Flux
如果对Flux并不了解，可以先阅读图解Flux噢。
一个Flux应用包括4个部分：
- Action，驱动Dispatcher的JavaScript对象，告诉Store数据发生了变化，以及哪里变化了（payload)
- Dispatcher，处理Action分发，维持Store之间的依赖关系
- Store， 负责存储数据和处理数据逻辑，就像MVC中的Model一样
- View，UI，负责显示用户界面。在Store数据变化之后，会自上而下完成一次渲染（re-render）。
解决的问题
MVC(Model-View-Controller)框架存在已久，大家也发现了很多的问题。其根本问题是不同模块之间的依赖关系复杂而且不可预测。对代码进行修改很容易引入bug。
比如你想象中的MVC是这样子的，
当其实它是这样子的：
所以为了解决这个问题，Flux推翻了MVC框架，用一个新的思维来管理数据流转--单向数据流。
Reflux
Reflux，是一个实现Flux设计模式的库，旨在使整个应用架构变得更加简单。
一个Reflux应用只包含3个部分：
- Action，负责消息的分发，一般是由用户行为触发
- Store，负责监听Action的触发，也负责通知View更新UI
- View，负责监听Store的数据变化，在Store数据变化之后，会自上而下完成一次渲染（re-render）。
解决的问题
Flux中Actions和Stores（消息订阅者）间存在着多对多的关系，而作为Flux中唯一的Publisher（消息发布者）Dispatcher，不得不在消息发布时，通过在payload中添加actionType字段来区分消息类型，且Store也因此不得不在回调函数中用Switch语句进行判断actionType处理。
而在Reflux中，由于每一个Action都是一个Publisher，且具有特定的含义（actionType），即多个Publisher对应于多个Subscriber（或叫做Listener），Store就可以有目的性地选择订阅想监听的Action，而不在监听所有的Action，再通过Switch语句进行筛选；另外，Action（消息）的发布，也只会通知给之前有订阅过的Store，而不是所有Store，所以并不会造成任何资源浪费。
综上所述，Reflux把Dispatcher的功能合并到Action中去，使得每一个Action都具有了消息发布的功能，可以直接被Store监听。
Redux
Redux是Flux设计模式的又一种实现形式。如果对Redux并不了解，可以先阅读图解Redux噢。
Redux中的三个核心概念时Action，Store和Reducer，当然一个Redux应用可能包含6部分：
- Action，一个用来代表所有会引起状态变化的行为的对象，一般都会包含一个字符串类型的type字段来表示将要执行的动作和需要传递给应用的其他数据信息（数据形式用户可以自定义）
- ActionCreator，一个函数，最终返回一个Action对象
-
Reducer，一个函数，该函数接受两个参数，一个旧的状态
previousState和一个Action对象，返回一个新的状态newState -
Store， Redux中数据的统一存储，维护着state的所有内容。Store通过
dispatch(action)方法来接收不同的Action，根据Action对象的type和数据信息，Store对象可以通过Reducer函数来更新状态的内容 -
Middleware，主要作用是处理Action，Redux中的Action必须是一个
plain object。但是为了实现异步的Action或其他功能，Action可能是一个函数，或者是一个promise对象。这是就需要Middleware帮助来处理这种特殊的Action。也就是说，Redux中的Middleware会对特定类型action做一定的转换，所以最后传给reducer的action一定是标准的plain object。 - View，UI，负责显示用户界面。在Store数据变化之后，会自上而下完成一次渲染（re-render）。
解决的问题
- 数据源不唯一
在 Flux／Reflux中，数据分布在多个Store中，很容易造成数据冗余，当数据存在重叠时，数据可能不存在唯一性，即在一致性方面会出问题。
解决方法
Redux提出单一Store存储数据。但这有可能面临另一个问题，数据结构嵌套太深，数据访问变得繁琐。
所以Redux提出通过定义多个reducer对数据进行拆解访问或者修改，最终再通过combineReducers函数将零散的数据拼装回去,将一个个reducer自上而下一级一级地合并起，最终得到一个rootReducer。
- 热重载
在Flux中，store包含两部分：
- State改变的逻辑
- 当前的State
将这两点放在同一个对象上则不能进行热重载。当你重载store对象来看state改变后的效果，你会失去store持有的数据。另外，你打乱了连接store到系统其他部分的事件订阅。
解决方法
拆分这两个方法。让store持有state，store将不会被重新加载。Reducer包含所有state改变的逻辑，reducer能被重新加载，因为它不需要关心持有任何state。这样就可以热重载state变化的逻辑(reducer)而不丢失store中所存储的state信息。
- 任何action的触发都会重写state
在时间旅行调试中，你跟踪每个版本的state状态。这样，你可以回溯到某一个较早的状态。
每次state改变后，你需要将旧的state追加到一个保存之前state的数组中。但是因为JavaScript的工作方式，简单的添加一个变量到数组中并不工作。这不会创建这个state对象的截图，只是创建了一个新的指针指向同一个对象。
为了让它工作，每个版本都需要一个完全分离的对象，以免你不小心修改到之前的某个版本的state。
解决方法
当store中接收到一个action，不要通过改变状态来处理它。而是拷贝原来的state，然后改变这个拷贝的state。
- 没有让第三方插件能能很好介入的地方
当你在开发开发工具时，你需要将它们写的更普遍一些。一个用户能够只将工具加进来，而不用去修改他们自己的代码来让它工作。
为此，你需要扩展很多点或面，能够让你的code可以添加一些新的东西到它里面。
一个🌰例子，打印日志。 当action被触发时，你需要打印每个action，然后你还需要打印通过action改变的state。在Flux中，你不得不监听dispatcher的更新，然后去更新每个store。但是这是自定义代码，而不是通过第三方工具来简单的完成这个需求。
解决方法
包装一部分系统到另一些对象中让它变得简单。这些对象在原始对象的基础上添加它们那部分的功能。你可以通过类似enhancers、higher order对象或middleware看出这类扩展的点。
另外，用树状结构去结构化state改变的逻辑。在整个state树被处理之后，store只需要触发一个事件就能通知到所有state改变了的view。
Redux有三大基本原则：
- 唯一数据源：整个应用只有一个Store，所有的数据源都是这个Store上的状态。
- 保持状态只读：不能直接修改Store上的状态，要修改Store的状态，必须通过触发一个action来完成，在改变状态时，不是去修改状态上的值，而是创建一个新的状态返回给Redux，由Redux来完成组装新的状态。
- 数据改变只能通过纯函数完成：这里的纯函数即Reducer，Redux中，Reducer函数不只是接受action作为参数，还接受state，它只负责技术状态，不负责存储状态。
References
[译]图解Flux[A cartoon guide to Flux]
[译]图解Redux - A cartoon Intro to Redux
