## 演职表 在我解释这些角色间如何交互前，先逐个介绍下它们。 ### Action Creator 第一个角色是 Action Creator。它负责创建 Action，作为全部改变和交互的入口。当需要改变应用的状态或有 View 需要更新时，你需要触发一个 Action。  我认为 Action Creator 就像电报员。你拿着你想要寄出的消息，找到 Action Creator，它就把消息格式化成系统其他部分可以理解的形式。 Action Creator 把 type 和 payload（载荷）封装成一个 Action。type 是你预定义的多个 type （通常是一个常量列表）之一，代表系统特定的 action。举个例子的话就像 MESSAGE_CREATE 和 MESSAGE_READ 这样的。 系统的某个部分知道所有可能的 action，这或许存在副作用。一个新来的工程师，打开 Action Creator 文件，看到全部的 API——所有可能改变的状态——它们都是你的系统提供的。 一旦 action 消息创建好了，Action Creator 就会把它传递给 Dispatcher。 ### Dispatcher Dispatcher 就是一个巨大的回调函数登记表。就好比一个坐在电话总机前的接线员。它保存着所有需要发送 action 的 store 列表。当 Action Creator 给过来一个 action，它会把这个 action 传递给各个 store。  Dispatcher 的行为是同步的，这对我之前讲的多个乒乓球游戏有所帮助。如果想要在 store 之间实现依赖，有的更新完了其他的才能更新，你可以使用 Dispatcher 提供的 waitFor() 来实现。 Flux 的 Dispatcher 不同于其他大部分架构中的 dispatcher。它会把 action 传递给所有登记在册的 store，而不在 action 的类型。也就是说 store 并不是订阅某些 action，而是聆听每一个 action，从中过滤它关心的。 ### Store 轮到说 store 了。store 保存了整个程序的状态，而且状态变化的逻辑都在 store 里。  我觉得 store 就是一个充满控制欲的长官。所有的状态变化都必须由它来亲自操作的。而且你不能直接通过 store 来更改状态。在 store 上并没有 setter API。要更新一次状态，你必须经过正当的手续——必须通过 Action Creator/Dispatcher 通道。 上面说了，如果 store 在 dispatcher 中注册了，那所有的 action 都会发给它。在 store 中，通常会使用一个 switch 语句来判断 action 的类型，决定是否对这个 action 做出相应。如果 store 关心这个 action，就会根据 action 找出需要变化的部分，更新 state。 只要 store 对 state 做出了变更，就会触发 change 事件，通知视图控制器状态已经变化了。 ### Controller View 和 View View 层负责将 state 渲染给用户，并接受用户的输入。  View 就像一个主持。它对应用一无所知，只懂该如何把交到它们手中的数据渲染格式化成用户能够理解的输出（HTML）。 Controller View 是一个中间管理者。store 在 state 变化时通知它，它收集新的状态，并将更新后的状态传递给所有大管辖的 View。