[译]Flux 架构与数据单向流动

flux 的概念(译)

原文地址：flux-concepts
我的英语水平不高。这是我第一次翻译英语文章，不足之处多多见谅…

当你在使用 Flux 写 app 的时候，你必须知道这些非常重要的高水平的概念与原则。

概览

Flux 是一种在应用程序中管理数据流动的模式，其中最重要的概念是数据是单向流动的。在这篇文章中我们将会讨论使用 Flux 设计应用程序的不同之处，并且展示数据是如何在应用程序中单向流动的。

Flux 的几个部分

• Dispatcher
• Store
• Action
• View

Dispatcher

Dispatcher 接收 Action 并且将他们分发给在 Dispatcher 上进行过注册操作的 Store。每一个 Store 都会接收到每一个 Action(原文：Every store will receive every action)。在每一个应用程序中都应该只有一个单例的 Dispatcher。

Example：

1. 用户在一个 todo 应用程序中输入标题并且按下回车；
2. View 捕获到这个事件并且将该事件封装成包含用户输入的标题、名字为"add-todo"的 Action，并将该 Action 分发出去；
3. 之后每一个 Store 都将接收到这个 Action。

Store

Store 含有应用程序的数据。Store 会向应用程序的 Dispatcher 注册以便 Store 能接收到 View 发出的 Action。Store 内的数据只能通过响应 Action 来改变(原文：The data in a store must only be mutated by responding to an action)。Store 不应该含有公开的 setter 方法，应该只含有公开的 getter 方法。Store 可以决定哪些 Action 是需要响应的。每当 Store 的 data 发生改变，Store 都应该广播出'change'的事件(原文：Every time a store's data changes it must emit a "change" event)。在一个应用程序中应该有很多个 Store。

Example:

1. Store 收到 View 发出的"add-todo"的 Action；
2. Store 处理这个 Action，从发送过来的 Action 内提取出用户输入的标题，并将其添加到今日需要完成的列表里；
3. Store 更新数据并且发出一个'change'事件。

Actions

应用程序内的 API 油 Actions 定义。它们捕获了任何可能与应用程序进行交互的方式。它们是包含有'type'字段与其他数据的、非常简单的 object。
Actions 应该是语义化并且具有描述性的。它们不应该详细描述它们在内部的执行细节。比如我们应该使用'delete-user'而不是使用'delete-user-id','clear-user-data','refresh-credentials'(或者其他任何过程化的工作)。请记住，Store 会接受到'delete-user'的 Action 并且知道他们需要做'delete-user-id'，'clear-user-data'，'refresh-credentials'等操作。

Example:

1. 当用户点击删除按钮，一个名为'delete-todo'的 Action 被分发出去了：

{
  type: 'delete-todo',
  todoID: '1234',
}

Views

数据从 Store 传来，并且在 View 上展示。在 View 层上你可以使用任何你喜欢的框架(我们更多的使用 React)。当一个 View 使用从 Store 那里获取到的数据的时候，它必须监听该 Store 的'change'事件(原文：When a view uses data from a store it must also subscribe to change events from that store)。之后当 Store 触发'change'事件的时候，View 可以立即获取到最新的数据并且重新渲染。如果一个组件使用了一个 Store 但是没有监听其'change'事件，那可能会具有一个等待被发现的 Bug。Actions 一般会通过用户的交互从 View 被分发出去。

Example:

1. 主界面监听了 TodoStore；
2. 主界面接收到了 Todo 的列表并且将他们渲染在了界面上；
3. 当一个用户输入一个新的 Todo 项的标题并且按下回车之后，主界面告诉 Dispatcher 来分发这个 Action；
4. 所有的 Store 都接受到了这个被分发的 Action；
5. TodoStore 处理了这个 Action，并且将用户输入的标题加入到内部的数据结构中，并触发一个'change'事件；
6. 主界面监听到了'change'事件，并通过 TodoStore 获取到了最新的数据，并将其重新渲染到用户界面上。

数据流

我们可以将 Flux 对数据的部分处理转化为图表。

1. Views 发送一个 Action 给 Dispatcher；
2. Dispatcher 分发 Action 给所有的 Store；
3. Store 响应事件，并且处理数据，将数据返回给 View。

• (换句话说：Views 从 Store 获取数据)
  
  (图中还有一个不是来源于 View 的操作，这也是很常见的)

下一步

在互联网上也有大量关于 Flux 架构的总结，如果需要的话可以自由的搜索更多你需要的资源。
另外，你可以开始尝试去写一个 flux-todomvc 的例子，或者返回查看 example topics 的列表。