zjhch123 / flux-concepts-chinese

flux-concepts中文版

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的列表。