对于React，更多是解决了UI层，也就是对于传统MVC中的View.至于Model-Controller 如果要整合React的代码又是如何实现呢？Facebook提出了一个叫做Flux([flʌks])的概念。
在传统MVC中，我们会遇到这样一个问题，随着项目功能和模块的增长，所产生的Model和对应的View就会多起来，而系统的复杂性也随之增加。如下图：
当然上图的情况比较极端，但也是一个不能不面对的问题，特别是有双向数据流产生的时候，就更难去解耦了。而Facebook所提供的Flux 是单向数据流的方式呈现，把MVC重新划分成Action ,Dispatcher,Store,View 四个重要的组件。如图：
当Action触发时，flux通过Dispatcher进行响应。换句话说，Dispatcher是一个中转站，它管理整个Flux架构的数据枢纽, 这看上去很像我们所说的Controller.而Store更接近我们的Model,负责数据的操作。但它也负责一些状态变化。Dispatcher其实是一个Store的回调注册。当Dispatcher响应Action时，通过已经注册的回调函数，将Action所提供的数据传送给对应的Store，而Store变化时，界面也会同步更新。
听上去有点复杂，我来说一个实例大家就会明白了，还是用回我们的主界面。我们把Facebook一个标准的Flux流图作为参考来说。
当要加载页面时，我们需要把Action Creators放在ComponentDidMount方法中，这样才能把最后的数据给页面。
Dispatcher要做什么，当然是把对应的Store回调处理好，如所对应的Action和返回的值。这里要说我们需要做一个ActionType为每个不同的Action事件做绑定（如增删改查）。所以在定义Dispatcher时需要定义一个APIActionID的枚举类型。如图：
注意：这个枚举类型，分别会为Store和Action作出对应ID。所以大家必须要注意。别以为没用了
还有一个基本的对应类型APIAction
Dispatcher的最后绑定是和APIAction做绑定
当我们在componentDidMount中使用Action时，它是通过Dispatcher去寻找Store的回调把数据传给Store保存，从而影响页面的变化的。
这里就是Action中的加载，最后是要把返回的结果给Store的，所以会通过Dispatcher绑定actionType,和返回的结果。而在Store中,就只需要对应好actionType即可。下面的的方法就是我们针对不同的actionType，Store所要做的事情。
Store涉及侦听回调事件，所以通过EventEmitter去完成.这里我们用到EventEmitter2
这个时候，只要能匹配好actionType，数据就可以顺利匹配上界面上了。
Flux不是一个新的技术，而是一个设计模式。对于Flux更多的是优化项目架构。或者你更习惯MVC/MVVM,但当模块增多的时候你会觉得它是更好的实现。
