React学习之认识Flux架构模式

Flux 是 Facebook 用户建立客户端 Web 应用的前端架构，它通过利用一个单向的数据流补充了 React 的组合视图组件，这更是一种模式而非正式框架，你能够无需许多新代码情况下立即开始使用 Flux。

• Flux 应用有三个主要部分：Dispatcher 调度、存储 Store 和视图 View(React 组件)，这些不应该和 MVC:Model-View-Controll(模型 - 视图 - 控制器) 混淆，控制器在 Flux 应用中是存在的，但是他们是 controller-view(控制器 - 视图)，视图通常在一个结构顶部，而这种结构是用来从存储 stroe 获得数据，然后将数据传递到自己的子结构们，此外，Action 创建者 -Dispatcher 的帮助类的方法 - 用于支持一个语义 API，这个 API 是描述应用程序中所有变化的可能，通常可将它们看成是 Flux 更新循环的第四部分。
• Flux 是以单向数据流方式支持 MVC，当一个用户和 React 视图交互时，视图会将这个动作传播到一个中央 Dispatcher，一直到各种存储，在那里保存着应用的数据和业务逻辑，这个使用 React 的声明式风格的过程是非常棒的，能够允许存储发送更新信息，而无需指定在状态之间如何切换视图。(传统方式更新状态后，会推出一个新的视图页面。)
• Flux 最初是用于正确导出数据，比如如果我们要显示一系列消息的未读数字，而另外一个视图显示的是所有消息，其中未读的消息会高亮显示。这种情况使用 MVC 很难处理，将一个消息变为已读状态需要更新消息模型，然后再需要更新未读的计数模型 (将未读模型数字减 1，因为刚发生一个已读改变)，这种依赖和级联更新经常发生在大型 MVC 应用，导致一个混乱的数据流编织和不可预知的结果。
• 控制器被存储反转控制：存储接受更新，适当地调节这些更新，而不是一致地依赖外部更新其数据，存储之外根本不知道它是如何管理领域数据的，这有助于实现一种清晰的分离关注。存储并没有直接的类似 setAsRead() 之类的方法，而是只有一个单一方式获取数据到其自成一体的世界中，这个方式就是回调，注册在 dispatcher 中的 callback。

结构和数据流

• 一个单向数据流是 Flux 模式的核心。dispatcher 存储和视图是有着不同输入输出的独立节点，Action 动作是一个简单对象，只是包含新的数据和一个标识符类型的属性。
• 视图也许引起新的动作 Action，这个动作作为用户交互的响应将在整个系统传播：

所有通过 dispatcher 的数据流将作为一个集中式 Hub，动作 Action 在一个 action creator 方法中被提供给 dispatcher，这个动作通常来自于视图中用户的交互，dispatcher 然后调用存储已经注册其中的回调函数，分发 Action 动作到所有的存储，在它们注册的回调函数中，存储会响应每个和它保存的状态有关的每个动作 Action，存储然后发射一个 change 改变的事件去提醒 controller-view 控制器 - 视图，更新到刚刚改变的新数据。controller-view 监听这些事件，然后在一个事件处理器中从存储中获取数据，controller-view 调用它们自己的 ”setState()” 方法，这会触发视图的重新渲染，包括 DOM 组件树中所有更新。

• 这个结构允许我们能够以比较理性的方式编程，这有点类似 functional reactive programming, or 或 data-flow programming 数据流编程或 flow-based programming。
• 通过应用的数据流是一个方向，没有两边绑定 (two-way bingding：Angular.js 有此方式)，应用状态在存储中维护，允许应用不同部分保持解耦，在存储之间发生依赖的地方，它们能够保持严格的层次关系（设计原则：尽量松耦合，无法回避的就变成树形层次结构），同步管理由 dispatcher 负责。而 two-way 绑定会导致级联更新，当一个对象改变导致另外对象改变，接着会触发更多的更新，当应用规模增长时，这些级联更新会使得预期响应用户交互的结果变得困难，当更新只会在一个轮回中发生改变数据时，整个系统就变得可预期。