新人第008天---初识flux

为了进一步了解redux,提前了解flux是有必要的,因此,把这篇通俗易懂的文章翻译一下,有助于自己以后理解。

A cartoon guide to Flux

图解Flux

目前的web开发界,flux是一个既流行又难懂的主题,因此,本文尝试使用一种通俗易懂的方式来解释其原理。

问题

首先,需要解释一下flux解决的基本问题。flux是一种在应用中处理数据的模式,与react共同诞生于Facebook并共同发展。尽管可以独立使用,但很多开发者都会选择同时使用react和flux进行开发。它们最初是针对Facebook遇到的一系列问题而开发出来的。

新人第008天---初识flux_第1张图片

在这一系列的问题中,众所周知的是Facebook的提示bug。当用户登录Facebook时,会发现消息图标上有一个消息提醒标志。当用户点击消息图标时,却发现根本没有新消息,而提醒标志也会随之消失。几分钟后,如果用户在站内进行了交互操作,那这个提醒标志就会再一次出现。用户又会再次点击...还是没有新消息。循环往复,如入怪圈。

新人第008天---初识flux_第2张图片
Facebook遇到的提示bug

不仅是用户,Facebook的开发团队更是对这个怪圈感到头疼。bug总是在修复后不久又出现了。如此循环往复,在bug与非bug中徘徊。

于是,Facebook开始想法设法摆脱这个怪圈。他们的目标不是仅仅单次修复bug,而是使整个系统更加可预测,这样他们才能确保这个问题不会不停地出现。

根本问题

根本问题在于,数据在应用中的流动方式。

注释:这是我从他们的谈话分享的简化版本中收集到的信息。可以肯定,真实使用的架构一定有所不同。

新人第008天---初识flux_第3张图片
模板把数据传到view层

模板负责存储数据,同时将数据传到view层中并对其进行渲染。

由于用户交互都通过视图实现,因此,视图有时需要根据用户输入更新模板。而有时,模板也需要更新其他的模板。

除此之外,这些动作有时会触发大量其他变化。我把这比作一场激动人心的乒乓球比赛,你很难知道球会落在何地(变化在何时何处发生)

新人第008天---初识flux_第4张图片
视图更新模板。模板更新其他模板。这看上去真的向一场激动人心的乒乓球比赛了。

当然,这些变化还可能异步发生。一个变化可能就会出发多个其他变化。我想,这就像在乒乓球比赛中把一袋子乒乓球倒出来,它们会飞得到处都是。

总之,这使得数据流debug变得十分困难。

解决方法:单向数据流

Facebook决定使用一种不同的架构,使数据只向一个方向流动-只有一个方向-每当你插入新数据,整个流程就会从头开始。他们把这种架构叫做flux。

新人第008天---初识flux_第5张图片
你可以在Facebook的flux文档中找到这幅图,它可以看上去酷多了。

它确实很酷,但是从上面这幅图中可能看不出来。

一旦理解了flux,这幅图就变得很清晰了。问题是,如果你是flux小白,又直接看了文档,那这幅图就对你的理解没什么帮助了(虽然它本来应该帮助你理解的)。在开始了解如何使用flux去做具体工作之前,这幅图应该帮助你对整个系统有个大体的了解。

而真正帮助我理解flux的不是像这样的图,而是对不同特征协同工作从而实现目标的系统的思考。接下来我会向大家介绍这些特征。

结识特征

我首先简单介绍一下这些特征,然后再介绍他们是如何联系在一起的。

动作创建机(The action creator)

第一个特征就是动作创建机。它负责创建动作,这也是所有变更和交互实现的方法。每当用户想改变APP状态或是渲染不同页面,都会发射一个动作。

新人第008天---初识flux_第6张图片
动作创建机像一个报务员,它负责为你格式化消息。

我认为动作创建机像一位报务员。你让动作创建机明白你需要发送什么信息,之后它就会用一种全系统可读的方式将其进行格式化。

动作创建机通过类型(type)和负载(payload)来创建动作。这个类型就是你在系统中的所定义的动作类型(通常是一个常量列表)。比如:MESSAGE_CREATE 或 MESSAGE_READ。

使你的系统知道全部可能的动作也有一定的副作用。一个新手开发人员可以参与项目,打开动作创建机文件,看到整个系统提供的API-所有可能的状态改变。

一旦动作消息被创建,动作创建机就会将动作传送给分发机。

分发机(The dispatcher)

分发机本质上来说是一个大回调注册处。这有点像电话接线总机处的接线员。分发机存储所有store,以便向这些store传递动作。每当一个动作从动作创建机被传递过来,分发机就会将这个动作传给不同的store。

新人第008天---初识flux_第7张图片
分发机就像一个电话接线员。它存储着不同store的所有回调信息。

分发机通过同步的方式来进行这样的操作,这样就可以帮助处理我之前提到的“多球乒乓比赛”效应。如果你需要在不同store之间建立独立性以便一个store可以在另一个之前进行更新,那可以使用分发机来管理(通过waitFor()函数)

flux的分发机与很多其他架构的分发机不同。动作都会被传入注册的store中,不管是什么类型。这就意味着,store不仅仅为某些动作而设计,而是会对所有的动作进行监听并且对其进行筛选,从中找出自己感兴趣的部分。

store

接下来是store。store存储着应用中所有的状态,以及每个store中状态的变更逻辑。

新人第008天---初识flux_第8张图片
store像一个权力过度的官僚。所有的变更都必须经过它。

我认为store像一位权力过度的官僚。所有状态变更必须要通过store。同时,也无法直接向store请求改变状态,因为store中没有设值函数。要想改变状态,就必须遵循适当的步骤。。。即必须要通过动作创建机/分发机途径来提交动作申请。

像我上述提到的,如果store通过分发机注册,所有的动作都会被传进来。在store内部通常有一个开关语句来监控动作类型,以决定该store是否关心这一动作。如果关心,该store就会指出需要据此动作作出何种改变并且更新状态。

一旦store对state做了改变,它就会发射一个变更事件。控制视图会被通知状态已经改变。

控制视图和视图(The controller view and the view)

视图负责获取状态,并且为用户渲染页面,同时也接受用户的输入信息。

新人第008天---初识flux_第9张图片
控制视图像一个中层管理者,从store处获取通知,并向下级视图传递数据。视图向用户展示数据。

视图是一个展示者。它不知道整个应用发生的事情,而只处理接受到的数据、将其转换为用户可理解的形式并进行输出(通过HTML)

控制视图像store和视图之间的中层管理者。store在状态发生改变时告知控制视图,而控制视图则接受新的状态并更新后的状态传递给下级视图。

他们怎样协同工作

现在,让我们看一下这些特性是如何协同工作的吧。

安装

首先需要安装:应用仅需要初始化一次。

1. store告知分发机,每当动作发生时,自己(store)都需要知道。

新人第008天---初识flux_第10张图片

2. 接着,控制视图向store请求最新的状态。

3. store将状态传给控制视图,控制视图就将这个视图顺次传递给其子视图去进行渲染。

新人第008天---初识flux_第11张图片

4. 当状态改变时,控制视图也会通知store。

新人第008天---初识flux_第12张图片

数据流

安装完成后,应用就可以接受用户输入了。那就让我们通过用户做变更来触发一个动作。

我们通过用户交互来讲解数据流。

新人第008天---初识flux_第13张图片

1. 视图告知动作创建机去准备一个动作。

新人第008天---初识flux_第14张图片
第一步

2.动作创建机创建动作并将其传到分发机中。

新人第008天---初识flux_第15张图片
第二步

3. 分发机将动作按序列传给store。每个store都会知道所有的动作。接着,store会挑出其感兴趣的操作并依此来改变状态。

新人第008天---初识flux_第16张图片
第三步

4. 一旦状态变更完成,store会通知相应的视图控制器。

5. 这些视图控制器会向store请求更新后的状态。

新人第008天---初识flux_第17张图片
第四步和第五步

6. 当获取到状态后,视图控制器会告知其子视图依据新状态进行渲染。

新人第008天---初识flux_第18张图片

这就是我对flux的所想所思。希望能帮到大家。



翻译的不够准确,有些术语还需要查证,日后还会继续更新。亟需批评指正~

未完待续。。

你可能感兴趣的:(新人第008天---初识flux)