漫谈FLUX

为什么需要FLUX？

react的核心是组件，严格意义上说react主要负责VIEW层的东西，当应用复杂程度高的时候，它的state会变得十分复杂，这个时候我们需要一个工具解决除了VIEW层之外的东西，所以我们需要FLUX。

什么是FLUX？

FLUX是FACEBOOK提出的一套前端应用架构模式，核心概念是单向数据流。注意它不是一个具体的框架，它有很多实现，比如REDUX，这些才是框架。

什么是单向数据流？

在MVC中数据流是双向的，MODEL<=>CONTROLLER<=>VIEW，同样面临在项目复杂度高的时候难以维护的问题。

而单向数据流是这样运作的，ACTION=>DISPATCHER=>STORE=>VIEW。

其中，ACTION是描述行为的对象，包含信息 ; DISPATCHER是信息的分发中心，它可以执行ACTION、注册回调函数、回调中处理STORE的内容 ； STORE被处理后，会向其他地方发送CHANGE广播，告诉别人我被变更了。VIEW接收到CHANGE信号之后，就可以改变UI。

所以一个使用FLUX的REACT项目的目录结构是这样的：

COMPONENTS存放组件、ACTIONS中注册程序中所有的ACTIOIN、DISPATHCER写程序中所有的调度、STORES则负责管理程序中数据的存放。

在ACTION就是行为，发生某个行为时，我们要告诉DISPATCH，DISPATCH要分发的其实是一个个对象，这个对象有个说明字段叫ACTIONTYPE，还有一个字段用来表明它所传递的信息。为了方便代码复用，FLUX提出了ACTION CREATOR的概念，举个《REACT全栈》这本书里的例子：

在一个TODOACTION里，有一个ACTION对象

const Todoaction={

//把DISPATCH分发的对象包裹在一个函数里。

create(todo){

Dispatcher.dispatch({

actionType:'CREATE_TODO',

todo

})

};

...

}

DISPATCH还有一个API,就是REGISTER，这个接口用于注册不同事件的处理回调函数，在回调函数中对STORE的数据进行处理。

我理解STORE就像一个数据库，负责增删改查及存储数据，除了STORE，任何人都不能对直接对数据进行处理。官方说法叫STORE是数据更新的唯一场所。

所以就是ACTION通过DISPATCH的时候触发回调函数来操作STORE，通过REGISTER来注册要触发的回调函数。

这种形式和PUB-SUB订阅发布模型比较像，但是是有不同的，很重要的一点是，DISPATCH的回调函数没有订阅到一个特定的事件或者频道中，REGISTER只接受一个函数作为回调，所有动作都发送到同一个回调。

《REACT全栈》里还提到了另一个重要区别，DISPATCH回调可以延迟执行，知道其他回调函数执行完毕。