#为什么需要Dispatcher
随着应用规模的增长，Store之间的相互依赖变得不可避免。Store A可能会需要 Store B先update，然后Store A才能知道如何update自己。我们需要Dispatcher以便在继续执行Store A回调之前，先行调用并完成Store B所注册的回调。要显式地声明这种依赖，Store需要向dispatcher表明“我要等Store B处理完了才能继续处理当前的action”。而dispatcher的waitFor则提供了这种功能。
dispatch方法提供了对所注册回调简单、同步式的遍历。而当在执行callback过程中遇到waifFor方法时，对当前callback的调用就会中断，wairFor方法会根据声明的依赖重新确定遍历顺序，当所有依赖都被执行后，原先中止的callback才会继续执行
更进一步地，waifFor方法可以在同一个store回调的不同action处理分支中使用。在某种情况下Store A可能依赖Store B，而在另一种情况下又依赖Store C。在action处理语句块中使用waitFor使我们能够更细粒度地控制依赖关系。
当然也会出现问题，比如循环依赖。A依赖B然后B又依赖A这样的情况，很可能会导致无限循环。目前Flux实现的dispatcher在遇到这种情况时会抛出一个包含错误信息的Error来警告开发者，然后开发者可以选择新建一个Store来避免这种情况。
#Structure and Data Flow
单向数据流是Flux的核心理念，事实上Flux的名字就来源于拉丁文的flow。在flux流程图中，dispatcher，stores与view是拥有不同输入输出的完全独立的模块，**action creaters**是一组独立的语义化的工具函数，用于将**action**形式的data传递给**dispatcher**
**dispatcher**是所有数据流的中央集线器，
