Web:一张图读懂Flux

问题

首先， 我来解释下Flux大概解决了什么问题。Flux是一种在app中处理数据的模式。在Facebook，Flux和React和并驱前行。大部分开发者一起使用它们，但是你可以为你自己所用。它们的存在是解决了Facebook当期遇到的问题

这一系列的问题中，最大的Bug莫非新消息通知了。当你登录Facebook了，你发现消息栏有提示了，你很自然的去查看新消息，事实上并没有新消息。这时，提示没有了。之后你已经刷了好几分钟好友的动态，新消息提醒又来了。你又去查看了，但是还是没有。就这样来回折腾。

这种循环不仅仅针对用户而言，同样也困扰了Facebook团队。他们修复了这个Bug，一切都恢复正常。这种正常状态仅仅只会维持一会儿，之后又会出现，再又去修复。反反复复。Facebook不得不寻找一个更合理的方式完全消除这个Bug。

潜在问题

他们发现潜在的问题存在于程序中数据的流动。

程序中有专门存放数据的models，并且会将数传递给view，渲染数据。
用户的交互发生在views，views有时需要根据用户的输入来更新model中的数据，有时model需要依赖其他model更新。

更重要的是，有时这些操作会引发一些级联变化。很难精准预测数据的走向。

事实上使这些数据可能会发生在异步，一个数据的改变可能会引发多个变化。基于以上，不便于开发者调式数据流。

解决方案：单向数据流动

一因此Facebook觉定尝试一种单向数据流架构–仅仅只有一个方向。当你插入新数据的时候，数据流从头开始进行。这就是Flux架构。

一旦你理解了Flux，这个图是相当清楚的。问题是，如果你从Facebook的文档入手，我不认为这个图可以帮助你理解它……这就是这篇文章应该做的。在你真正开始搞清楚你怎么做具体的事情之前，你应该有一个系统的理解。。

角色划分

在我解释一下它们是如何相互影响之前，先让我只是去给一个快速的文字介绍。

The action creation 行为创造者

第一个角色是行为创造者。它是负责创造行为，所以的改变和交互都会经历这一步。无论何时你打算改变app的状态或者改变一下view，你都讲触发一个action。

我把行为创造者比作一个报务员，当你访问action creator的时候，它知道了你将要发送什么信息，稍后它整理这些数据，方便数据流中其它成员认识这些数据，

The action creator创造一个带有type 和 payload的属性（暂且叫属性，这样好理解）。一般这个type是你自己定义好的action（一般是一列常量）。就像这样：MESSAGE_CREATE or MESSAGE_READ.

一旦它创造了action消息，action creator将action传递给dispatcher(调度员)

The dispatcher 调度员

调度员基本上是一个回调的注册表。这有点像一个电话接线员在电话总机。它保持所有它需要发送操作到stores（商店）的列表。当一个动作来自动作创造者，它会来回传递的行动不同的stores。

这是一个同步调用。如果你想要设置stores之间的依赖关系，为了数据更新有个先后顺序，你可以让dispatcher用waitFor()为你管理这些顺序。

Flux dispatcher与许多其他架构的dispatcher不同。不管这个action是什么动作类型，该动作会被发送给所有注册过的商店。这意味着stores不只是订阅某一些actions。它监听所有的action，并筛选出它所关心和不关心的。

The store

接下来就是store了。store保存了程序中所有的状态。

我把store比作为一个过度控制人员。所有状态的改变都必须亲自由它处理。你并不能直接请求并改变状态。在store内没有 setter。为了请求状态改变，你必须得遵循一些列流程。。。你必须通过acion creator 和dispatcher pipeline提交一个action。

正如我上面提到的，如果store注册到l了dispatcher，所有操作将被发送给它。在store内通常有一个switch语句，查看操作类型，以决定这个store是否不关心这个action。若该store不关心这个action，它会找出在该action的基础上与之相对应的操作，改变和更新状态。

一旦store已经完成了状态的改变，它将emit(发射)一个change event（变化事件）。它将通知controller view，某个状态已经改变。

The controller view and the view

view负责获取状态，为用户渲染数据同时接受用户的输入。

View负责展示数据。在程序中它感知不到任何数据的变化，它就知道有数据传递给它了，它得以合理的方式输出数据（以html的形式）。

Control view就介于store与view之间。store告诉它某个状态什么时候改变了。它收集了新的状态，然后将已经已经更新的状态全部传递给view.

它们如何协作

初始化

让我们来看看它们是如何一起运作的。

首先需要设置一下：程序初始化哪些action只发生一次。

1.store告诉dispatcher，任何时候有action进来的时候，它们都会收到通知。

2.接着controller views向stores索要最新的状态。

3.当store传递状态给controller view 的时候，controller view将状态传递给child view去渲染。

4.controllre view 也会让store随时保持警惕，因为状态改变了，它就会收到通知。

数据流

一旦初始化完毕，程序就可以接受用户的输入了。让我们通过用户的的请求触发一个action。

我们将随着用户的交互开始一个数据流动。

1.viewa通知action creator准备好一个action

2.action creator 格式化该action 并且把它发送到dispatcher。

3.dispatcher按顺序发送动作到store。每个store得到所有action的通知。接着store决定是否关心这个action，并相应地改变状态。

4.一旦store完成了状态的改变，store让订阅了该action的controller views 知道。

5.那些controller views将想store请求数据，更新状态。

6.store传递状态之后，controller view将会通知它的子代view根据新的状态更新数据。

参考
https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207#.b83quahme

https://facebook.github.io/flux/