解读:Flux 是什么?

xjygabc00 2017-07-11

Flux被称为React全家桶的明珠、前端摆脱MV*的救赎、Facebook海量复杂数据的基石。本文的目标是通过了解Flux 提出的模式,来明白Flux 的核心要点,以及弄清楚它到底是什么。并且,由于Flux 不是传统意义上的软件包,因此我们将仔细研究通过Flux 来解决设计思路上的问题。

本文选自《Flux架构》

Flux 作为一种全新的方式,用于支持建立复杂的可扩展用户界面。当你在网上搜寻Flux的相关资料时,能了解到的大概也就是类似以上这些内容了。但我们该如何定义这样一种全新的方式呢?又是什么让其优于其他前端架构呢?

Flux 是一套模式

我们可能首先会在理解上遇到严酷的现实——Flux 并非软件包;其实,它是一套方便我们去遵循的架构模式。这听起来似乎令人失望,不过别难过,有很好的理由不将其作为一个框架来实现。相比实际实现,在贯穿本书的内容中,我们将会看到Flux 作为一套模式而存在的价值。现在,让我们开始了解Flux 中的一些上层架构模式吧。

1 .数据入口

在传统前端架构设计中,我们很少考虑如何处理系统的数据入口。我们可能对此有个初步的方案,但是并不具体。例如,通过MVC(模型-视图-控制器)架构,让控制器来控制数据流。通常,这很有用。但另一方面,控制器实际控制的只是当数据已经存在后所发生的事情。那么控制器该如何在一开始就获取数据呢?如下图所示。

解读:Flux 是什么?

初看此图,似乎没什么问题。以箭头标识的数据流应该很容易跟踪。但数据从哪里来的呢?例如,通过用户事件,视图可以创建新的数据,并传递给控制器;根据各控制器之间的层次关系,一个控制器可以产生新数据并传递给另一个控制器。但关于控制器,它能自己创建数据给自己使用吗?

在类似这样的图中,这些问题看起来并不重要。但是,如果我们尝试将它扩展到拥有数百个类似组件后,数据入口在这个系统中的地位就非常重要了。因为Flux 是一种用于复杂系统的可扩展架构,所以在这种架构模式下,数据入口是十分重要的。

2 .状态管理

状态是我们在前端开发中经常需要处理的。不幸的是,我们难以在无任何副作用的情况下整合所有的纯函数,这有两个原因:第一,我们的代码需要与DOM 有正向或反向的交互,这也是用户在界面中所能感知到的;第二,我们不能把程序里所有的数据都存在DOM中(至少现在不能),这些数据会因为时间的推移和用户的操作而发生变化。

在Web 应用中,并没有现存的状态管理的方法,但有多种方式来限制状态改变的数量,以及规定如何发生改变。例如,纯函数不能修改任何状态,它们只能创建新数据。以下是 一个类似的示例。

解读:Flux 是什么?

正如你所看到的,此处的纯函数并没有副作用,因为,任何对它们的调用,都不会导致状态的变化。如果状态的改变是不可避免的,那么为什么还要采用这种做法?我们的方法是规定状态在哪里改变。例如,如果只允许部分组件类型可以修改程序里的数据状态,这样,我们就可以掌控哪些源可以引起状态变化。

Flux 十分擅长控制状态在哪里发生改变。在后面部分,我们会看到Flux 存储器(Stores)如何管理这些状态的改变。Flux 如何管理状态的重要性所在,是它在架构层上的处理。设计一套规则来决定哪些组件类型可以变更程序数据,这让我们感到很困扰,而相对于此,通过Flux 则不需要花费什么精力来考虑在哪里更改状态。

3 .保持同步更新

数据入口点是同步更新的重要概念。也就是说,除了管理该状态变化的来源,我们还必须要管理这些相对于其他事务的变化顺序。如果数据入口点就是我们的数据,这时候我们应该同步地将状态的改变应用到系统中的所有数据。

让我们花点时间想想这为什么如此重要。在系统中数据被异步更新时,我们必须考虑竞争条件。竞争条件可能会产生问题,因为一个数据可能依赖于另一个,如果它们以错误的顺序更新,我们会遇到一连串的问题。下图说明了这个问题。

解读:Flux 是什么?

当事务是异步的时,我们无法控制何时发生状态改变。因此,我们所能做的就是等待异步更新发生,然后检查数据,并确保满足所有的数据依赖。没有自动化工具为我们处理这些依赖,我们只能写很多代码来检查状态。

Flux 通过确保同步更新数据存储器解决了这个问题。这意味着,上图所示的情况不会发生。下图更好地展示了Flux 是如何处理当今典型的JavaScript 应用程序中的数据同步问题的。

解读:Flux 是什么?

4 .信息架构

我们常常忘记自己置身于IT 行业,应该围绕信息发展技术。然而近期,风向大变,在新形势下,我们在探讨信息之前被迫考虑实现。通常,应用中所用的数据源暴露出的数据,并不是用户想要的。我们需要JavaScript 将这些原始的数据变成用户可接受的数据。这就是我们的信息架构。

这是否意味着Flux 被用于设计信息架构,而不是软件架构?并非如此。实际上,Flux组件被实现为真实软件的组件,用于执行实际计算。诀窍是,Flux 模式使我们可以将信息架构作为首要的设计考量。不是非得通过各种组件及其实现问题来进行筛选,而是我们可以确保得到正确的信息给用户。

一旦我们的信息架构初具规模,更大的应用程序就会接踵而至,作为一种我们试图传达给用户信息的自然扩展。从数据中产生信息是困难的部分。我们不仅仅需要从大量的数据源中提取信息,并且这些信息也必须对用户产生价值。在任何项目中犯这种错误都将面临巨大风险。当处理正确时,我们就可以继续处理特定的应用程序组件,如按钮控件的状态等。

Flux 架构保持数据在存储器中进行转换。存储器是一个信息工厂,原始的数据进入,新的信息产出。存储器控制数据如何进入系统、同步状态变化、定义状态如何变化。当我们深入了解存储器后,将看到它们如何成为信息架构的支柱。

Flux 并不是一个框架

现在,我们已经对Flux 的上层模式进行了一定的探索,让我们再来想一下:什么是Flux?其实,它只是一组可以应用到前端JavaScript 程序中的架构模式。因为Flux 将信息放在首位,从而使其具有良好的扩展性。信息是软件中很难扩展的一部分,而Flux 推进了对信息架构的处理。

那么,为什么不将Flux 模式实现为一个框架呢?如果这样的话,Flux 需要提供一个标准实现给大家使用,像其他的大型可扩展开源项目一样,其代码也需要随着项目的发展而不断更新。

现在主要的问题是,Flux 是在架构层上运行的,它用于解决阻碍已有程序扩展的信息问题,以满足用户需求。如果Facebook 决定以一个框架的形式去发布Flux,那么就会遇到类似其他框架发展的困扰。例如,一些框架的组件不能在工作中以最适合的方式实现,如果不侵入框架,那就很难去实现一个更好的方案。

Facebook 决定放弃实现完整的Flux 是多么棒啊!他们确实提供了少量的Flux 组件实现,但仅供参考。这些实现是有用的,但主要用来作为我们理解运作机制的起点,例如分发器如何像预期那样工作。我们可以随意以我们了解的相同的Flux 架构模式来进行实现。

Flux 并不是一个框架,这是否意味着我们需要去自行实现Flux?不,不需要。实际上,开发者正在实现Flux 库,并将它们开源。一些Flux 库很贴近Flux 的架构模式;另一些Flux实现库有自己独到的理解,使用它们并不会有错,只要合适就行。Flux 模式旨在基于JavaScript 开发解决通用概念问题,因此在深入探讨Flux 实现之前要掌握其定义。

Flux 的设计思路问题解决方案

如果Flux 只是架构模式的集合,而不是一个软件框架,那么它能解决什么样的问题呢?我们将从架构角度来看Flux 所能解决的设计思路问题,包括:单向数据流、可追溯性、一致性、组件分层和低耦合组件。这些问题都会在我们的软件中产生风险,尤其是大型可扩展应用。Flux 可帮助我们摆脱这些问题。

1 . 数据流向

我们正在建立一个信息架构,使得具有复杂功能的应用能够在此之上构建。数据流入系统,并最终到达终点,从而结束整个流程。在入口点和终止点之间所发生的就决定了Flux架构的数据流,如下图所示。

解读:Flux 是什么?

数据流的概念是一个很好的抽象,因为这可以很好地去可视化数据的流向,你可以很清楚地描述它如何进入系统,然后从一个点移动到另一个点,最终流动停止。但在它之前,会有些副作用发生,那就是上图的中间块所关心的问题,因为我们不能确切地知道这个数据流是如何到达终点的。

比方说,我们的架构并不对数据流有任何限制。任何组件都允许将数据传递给其他组件,无论组件的层次在哪里。请看下图。

解读:Flux 是什么?

正如你所见,我们的系统已经很明确地定义了数据的入口和出口。这太棒了,因为这意味着我们可以很自信地说出流经系统的数据流。但问题是,系统中各组件之间的数据流并没有在这张图中展现。图中数据流是没有方向可循的,更确切地说,是多方向的,这糟糕透了。

Flux 是一个单向数据流架构。这意味着,上图中的组件层是不可能出现的。现在的问题是,为什么说多向数据流不好?有时候,我们会觉得数据在各组件之间以任意方向传递。

是很方便的,这并不是个问题,因为传递数据不会破坏我们的架构。然而,当数据在系统中的移动是多方向的时,我们需要花更多的精力去为它们同步。简单来说,如果数据没有按照一致的方向进行流动,就有出错的可能。

Flux 强制数据流的方向,因而降低了因组件更新顺序不当而破坏系统的可能性。无论什么数据进入系统,都应当按照同样的顺序流入系统,如下图所示。

解读:Flux 是什么?

2 . 可回溯性

我们知道,当数据流单向地从系统进入组件中的时候,很容易预测和跟踪所有可能会产生的影响。相反,当一个组件向其他任何一个组件发送数据的时候,却很难捕捉到数据是如何到达的。为什么会这样?通过调试器,我们现在很容易地可以在运行时遍历任何一级,无论有多复杂。但这个概念的问题在于,我们只是调试我们所需要的。

Flux 架构中的数据流本质上是可预测的。这对于许多活动设计都是十分重要的,而不只是局限于调试。所以在用了Flux 架构的应用中,程序开发者能很直观地知道即将发生什么。这种预期是很关键的,因为这样可避免让我们设计出死胡同一样的程序。当我们能够很容易地弄清楚因果时,就可以将大部分时间花在构建应用的功能上,因为这才是用户真正关心的。

3 .通知的一致性

在Flux 应用中,我们从一个组件向另一个组件发送数据时,需要保持数据流向的一致性。在保持一致的时候,还需要考虑系统中的数据流向机制。

例如,分发和订阅就是一个在组件间通信十分流行的机制。这种方法所带来的好处就是,我们的组件可以相互通信,并且保持一定程度上的解耦。事实上,这在前端开发中是相当普遍的,因为组件的通信都是由用户的事件所驱动的。这些事件可以被认为是“即发即弃”的。任何其他组件想在某种方式上响应这些事件,都需要去订阅这个特定的事件。

分发和订阅的机制虽然有它的优点,但它在架构上也遇到了挑战,尤其是在大型复杂的应用中。例如,为了开发某项新功能,我们增加了几个新组件,但是以下这几点一直会困扰着我们:这些组件应该接受来自已有组件的消息更新吗?它们会得到这些更新响应的通知吗?它们应该先响应吗?这就是复杂性所带来的数据依赖问题。

分发和订阅带来的另一个挑战就是,我们有时需要先订阅一个通知,而后取消该订阅。这样,当我们试图在拥有众多组件的系统中,去尝试保持组件完整的生命周期,不仅十分困难,而且会增加丢失事件捕获的几率,从而破坏了一致性。

Flux 方法,则是通过维持一个静态的内部组件信息树,来规避上面的问题,从而将消息分发到每个组件中去。换句话说,程序开发者并不需要去挑选组件所需要订阅的事件,而只需要区分出分发给它们的事件中哪些是相关的,剩下的则可以忽略。下面是关于Flux如何分发消息的示意图。

解读:Flux 是什么?

Flux 分发器给每个组件发送事件,没有其他机制可以绕过这种方式。我们需要实现组件内的逻辑来判断此消息是否有用,以取代对消息结构的篡改而导致的难以扩展的问题。并在组件内部来声明对其他组件的依赖,这样对接下来的数据流向很有帮助。

4 . 简捷的架构分层

分层是一种对组件进行组织的很好的架构方式。一方面是因为分层能够对应用的各种模块进行明确的分类,另一方面是因为分层可以对通信路径做出限制。后一点与Flux 架构尤其相关,因为保持其数据流的单向性是十分重要的,而对分层做限制比对独立组件做限制要容易得多。下面所示的是Flux 分层的示意图。

解读:Flux 是什么?

上图主要描绘了数据在三个分层之间是如何流动的。

从上图中可以看到,数据从一个分层流向下一个分层,并且保持同一个方向。Flux 仅有几层,应用的规模以组件数量来衡量,而分层的数量仍然是固定的。当给一个已经很庞大的应用增添新特性时,会使其复杂度达到上限。所以,除了限制分层数量和数据流方向,Flux 架构也限制了哪些分层可以与其他分层进行通信。

例如,动作层(Action Layer)可以与视图层(View Layer)进行通信,并且该通信是单向的。我们可以编写Flux 设计的分层,并且不允许跳过某个分层。确保一个分层只能与位于其下紧邻的分层进行通信,可以避免无序引入的代码问题。

5 . 低耦合渲染

Flux 设计的一个亮点在于架构不用关心UI 元素如何被渲染,也就是说,视图层与架构的其他部分是低耦合的。这样设计是有原因的。

Flux 首先是一个信息架构,其次才是一个软件架构。我们将首先学习其作为信息架构的思想,最后会学习其作为软件架构的思想。我们知道,视图技术的缺点是它会对架构的其他部分产生副作用,例如一个和DOM 进行特殊交互的视图就会产生这样的影响,所以,一旦我们决定使用这项技术,它势必会对信息架构的组织方式产生影响。这并不一定是件坏事,但它将导致我们对最终呈现给用户的信息做出妥协。

实际上,我们真正应该思考的是信息本身,以及信息是如何变化的。哪些相关行为会导致这些变化?数据之间是如何依赖的?Flux 不受当下浏览器技术的限制,这使得我们可以优先关注信息本身。因此,在信息架构中插入视图使其变为软件产品是很容易的。

《Flux架构》

解读:Flux 是什么?

React全家桶的明珠 前端摆脱MV*的救赎 Facebook海量复杂数据的基石

作者:[加] Adam Boduch,译者:段金辰、马雪琴、李胜、马飞 等

图书链接:https://item.jd.com/12104517.html

相关推荐