flux不是一个具体的框架，而是Facebook提出的一种代码架构。
React只是一个视图库，mvc中react只是v，flux是在React基础上对于前端整体的组织方案。Flux中包括了存储(store)，动作(action),分发器(dispatcher),视图(view)，我们可以理解成react只是flux中的一部分，flux中可以不采用react，使用一些其它类似的来代替，都没有关系。它只是一种设计思想，它并不局限于某种框架。为什么facebook会推出它，传统的mvc只适用中小型系统，对于大型系统来说，mvc复杂度过高，因为mvc一般来说，一个m或者一个v都会对应一个c，他们会有一个对应关系，如果mvc的其中一部分变得非常复杂，那么就会导致整个mvc结构非常庞大，并且逻辑关系，依赖关系非常复杂。
**flux的目的就是保证逻辑清晰，数据流向清晰，依赖关系清晰。**当你用mvc来开发一个大型项目的时候，你会发现很多是耦合的，你不知道一个操作会产生什么后果，你修改了一个m，会导致很多c很多v 无法正常工作，因为他们之间的关系非常隐蔽非常复杂。但是fulx中，把这些关系都清晰罗列出来，并且每一部分，都专注于自己的事情，而且数据流是单一的，这和react中的思想是一致的。flux贯彻了这一点，在整个项目中都保证了单向的数据流动，这就大大减少了整体的依赖关系，复杂关系。
上图为flux的数据流动图，从中我们可以看出其分四个大块，Dispatcher，Store，React Views，Action Creators。
我们从一个简单的小列子来读懂这张图：我们构建了一个表单，当用户输入一个值后，其会触发User Interactions，这个时候就会把这个触发操作，传递给action creators，这个action creators 会根据你的要求来产生一个action，比如说输入一个值，那么产生一个对应的action，这个action会传递给dispatcher,dispatcher可以理解成一个大脑，它接受到这个aciton之后，它会处理这些数据，这个本质上就是一个数据在不断流动，dispatcher中会调用不同的store，sotre就是mvc中的m，你可以这么理解，当然他们中有些差别，总的来说store就是用来存储数据。每建立一个新的sotre，就会向dispatcher中去注册，等于我告诉dispatcher，我这里有一个新的store，如果你需要就来找我。这样的话如果有一个action到达dispatcher，然后就会去dispatcher中找，谁能处理这个action，比如说这个表单，对应一个store，dispatcher找到之后就会说，我找到了你的store，然后就会把这个action传递给store，因为store在注册的时候会告诉dispatcher有个回调函数，也是就是callback，所以说dispatcher就可以通过回调函数把一些操作发送给store，这个时候数据就流动到了store，sotre拿到数据后，就是非常简单了，进行一些增删改查，完毕之后，它会发出一个event事件，广播一个事件，比如说，它添加了一条记录，它就会发出一个事件说，我添加了一纪录，这个事件就会广播到整个view，如果view中有人关心这个事件，我们知道view中可能有很多东西，比如评论，表单，用户，文章等组件，但是每个组件关注的数据不一样，比如说表单组件收到这个更新表单的事件，它就会知道这是我需要的，它就会向sotre获取新数据，store就会把更新后的数据给veiw，view拿到数据后setState来更新自己的状态，状态更新之后了就会触发对应的reader，界面就会发生变化。这个完整的流程就结束了。
数据流向的简单总结：首先是view界面，用户进行操作之后，view会触发一个action，action负责具体的操作，action知道了你的改动之后就会操作传递给你的dispatcher，dispatcher拿到你的操作之后就会去找对应的store，把操作应用进去。store修改玩数据之后，会广播一个事件，事件广播出来之后，哪个view关心哪个veiw就去要数据，更新整个组件视图。
一般来说我们不止一个view，一个dispatcher，他们之间不是一对一的关系，也就是说不必非要一个store对应一个view，一个store可以对应多个veiw，一个view也可以对应多个action。这样做了分层抽象思想，store中处理数据的时候不用担心谁去用它，它的作用只是单纯的处理数据，view拿到数据后，不同的view会根据不同的情况进行展示，这个跟store没有关系，这样就解耦开了，同样action，dispatcher原理也一样，这样的抽象，分层，就可以比较好的提高聚合度，减少耦合性。