[译]看漫画学Flux

原文地址：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)

调度人员有一个大的回调(callbacks)注册表(registry)，在某种程度上像电话交换机上的接线员，保留数据层(store)中须要发送的行为列表。当行为被行为建立者建立后，调度人员会将行为发送给不一样的数据层。
调度人员以同步方式完成工做，若是你须要在数据层之间设置依赖关系，以便在其余数据层更新前更新，你可让调度人员使用waitFor()进行管理。

Flux的调度人员与其余不少架构中的不一样。不管行为类型是什么，它都会被发送到全部的注册数据层里。这意味着数据层不只仅收到一些行为消息，而是接收所有消息再就实际状况过滤。

数据人员(Store)

接下来就是数据人员了。数据人员掌控这程序里全部的状态，以及状态的改变逻辑。
我把数据人员比喻成权力极大的爷，全部的状态改变必须由他亲自完成。你不能直接要求他改变状态，要请求更改状态，你必须遵循适当的步骤：经过行为建立者或调度人员提交行为。

正如我以前提到的，若是一个数据层被调度人员注册，全部的行为将会发送到那里。在数据层里，数据人员通常会用一个switch语句查看行为类型，以决定这个数据层是否关心此行为。若是数据层关心此行为，那么数据人员会根据这个行为找出须要作出哪些更改并更新状态。
一旦数据人员改变了状态，他就会提交一个改变事件，这会提示视图控制员知道状态变了。

视图与视图控制员(Controller view & view)

视图负责拿到状态并将其渲染出来给用户看，以及接收用户输入。
视图是一个展现者，他并不知道程序里发生任何事，只知道接收到的数据，以及如何将数据格式化成用户能理解的方式（经过HTML）。
视图控制员更像一个在数据人员和视图之间的中层经理，数据人员告诉他状态何时变了，他收集到新状态再将更新状态发送给他的子视图。

他们怎么一块儿工做

接下来看看这些角色怎么共同工做的。

初始化(setup)

首先有个初始化：只发生一次的程序初始化。

• 数据员(stores)使得调度员(dispatcher)知道，不管什么时候有行为(action)来了，数据员须要被通知。

• 视图控制员(controller views)向数据员(stores)询问最新状态(state)。
• 当数据员向视图控制员说明了状态后，视图控制员把这个状态告诉其子视图去渲染。

• 视图控制员也告诉数据员当其状态改变时记得通知本身。

数据流(date flow)

一旦初始化完成后，程序就准备好接收用户输入。如今，咱们假设用户作改变引发了一个行为(action)。
咱们经过用户交互来启动数据流。

• 视图(view)告诉行为建立者(action creator)准备行为。

• 行为建立者格式化行为并发送给调度员(dispatcher)。

• 调度员按顺序将行为发送给数据人员(store)，每一个数据员都收到了全部行为的提示，接着数据员筛选哪些是他关心的，再相应地改变数据层状态(state)。

• 一旦状态改变，数据员就会让当时须要他通知的那些视图控制员知道其状态变化。
• 这些视图控制员会向数据员要他们更新后的状态。

• 在数据员给了本身更新后的状态，视图控制员就会告诉其子视图根据新状态从新渲染。

这就是我认为的Flux，但愿对你有用！

译者：若有翻译错误，请指正哟，谢谢！(＾Ｕ＾)ノ~ＹＯ