前端Flux架构简介

      前端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架构

一个单向数据流是Flux模式的核心,上面示图应该是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绑定会导致级联更新,当一个对象改变导致另外对象改变,接着会触发更多的更新,当应用规模增长时,这些级联更新会使得预期响应用户交互的结果变得困难,当更新只会在一个轮回中发生改变数据时,整个系统就变得可预期。

发表评论

电子邮件地址不会被公开。 必填项已用*标注