原文地址：A cartoon guide to Flux - by Lin Clark
Flux在目前web开发中最受欢迎也较不被人理解，本文会以简单易懂的方式解释它。 出现问题
首先，我要声明Flux所解决的基本问题。Flux是一种帮助你处理数据的模式。Flux和React都由Facebook开发。许多人把他们放在一起用，当然你也可以单独使用它们。它们的形成是为了解决Facebook所面临的一系列典型问题。
这些问题中一个广为人知的例子就是关于通知的错误(notification bug). 当你登录Facebook时，你会通过消息图标(message icon)看到一则通知(notification)。然而你点击消息图标后，可能根本没有新消息，通知消失了。接着，在与网站进行几次交互之后，通知又回来了。你再一次点击消息图标...依然没有新消息。这个情况会在循环中继续往复发生。
这不仅仅是发生在用户里的循环，对于Facebook团队里也会有这个循环。他们修复了错误，一切在一段时间里看似表现很好，接着错误又回来了。这一直处于解决问题和再次出现问题之间来回切换。
所以Facebook在寻找跳出死循环的方法。他们不想仅仅是修复一次bug，他们希望保证系统可预测，这样他们就能确保问题不会重新出现。 根本问题
他们发现根本问题在于数据流经应用程序的方式。
住：这是我从他们的分享会上展示的简化版本中收集到的，我确定实际的架构看起来并不一样。
他们有保存数据的模型(Model)，并将数据传递到视图层(View Layer)渲染。
因为用户交互发生在视图层，视图有时候需要根据用户输入来更新模型。有时模型还需要去更新其他的模型。最重要的是，这些行为有时会引发其他一系列的变化。我认为这非常有趣，因为你无法知道接下来会发生什么！（作者此处用了比喻，I envision this as an edge-of-your-seat game of Pong — it’s hard to know where the ball is going to land (or fall off the screen)）
不考虑这些变化会引起异步发生的可能性。一个变化可能会一起多种其他变化。我想这就好像抛出一袋乒乓球到乒乓游戏中，随着他们飞过整个地方并穿过小径。
总而言之，它使得调试数据流变得很困难。 解决方案：单向数据流
Facebook觉得尝试一种不同的架构，数据向一个方向流动——只有一个方向——当你插入新数据时，这个流程就从头重新开始。他们称这一架构为Flux。
实际上这个技术非常棒...但你可能无法从上面这张图里看出来。
一旦你理解了Flux，这张图就显得非常清晰。问题是如果你要找到对Flux完全新的文档，我认为这张图不能帮助你理解它...这就是图应该做的事。在你开始深入了解如何做特定事情之前，图会让你对系统产生一个全面的了解。
帮助我更好理解Flux的不是这样的图，而是根据团队中不同角色要实现共同目标来考虑这个系统。所以我会想你介绍我脑子里的这些角色。 角色
在我将这些角色联系起来之前，我先对各个角色做简单介绍。
行为创建者(Action)第一个角色是这个行为创建者。他负责创建行为，这是所有改变和交互必须经历的路径。无论你是否想改变程序的状态，或者让视图的渲染方式不同，你都需要创建行为。
我认为行为创建者就像电报员。他知道你想传递什么消息，接着再以其他系统可以理解的方式格式化信息。
行为创建者创建行为时，会伴随一个type和一个payload。type表示你在系统中定义为行为的类型之一（通常是常量列表），比如MESSAGE_CREATE或MESSAGE_READ。
让系统的一部分知道所有可能的行为有一个很好的作用，那就是，当新人参与到项目里时，打开行为创建者的文件就能看到整个API——系统提供的所有可能的状态改变。
一旦创建了行为消息，行为创建者就会将该行为传递给调度人员。 调度人员(Dispatcher)