Flux学习(一)

一、基本概念:

Flux是Facebook用来构建客户端Web应用的架构,通过单向数据流的方式来实现React的视图组件与Model之间的数据流动。与其说它是正式的框架,倒不如说它是一种模式。

Flux应用主要由三大部分组成:dispatcher,model,view(React视图组件)。在这里,并没有MVC架构中的controller这一层。但是它有controller-views。controller-views-view处于分层结构的顶部,负责订阅store中的数据并依次传递给它的children。dispatcher负责分发事件,model负责保存数据,响应事件以及更新数据,

二、结构与数据流:

图1.1

用户输入action creator 将action提供给dispatcher → dispatcher触发在store中注册的回调函数,将action派发给所有store 在回调函数内,store对每一个action做出响应并更新状态 store随后触发了一个change事件去提醒controller-views数据层发生了更新 → controller-views监听这些事件并在事件处理器中订阅这些数据  controller-views调用自身的setState()触发自身以及子视图的重新渲染

在此过程中,数据流向都是单向的。应用状态只保存在store中,使得应用其他部分高度解耦。在store之间存在依赖关系时,它们保持了严格的分层,由dispatcher来管理同步更新。

而双向数据流会导致级联更新。发生在一个对象内的变化会导致另一个对象也变化,这会导致更多的变化。随着应用变得复杂,级联更新将会导致用户与界面的交互结果变得不可预知。而如果数据流向都是单向的话,系统整体便可预测。

三、Flux架构的各个部分

3.1 Dispatcher

在Flux应用中,dispatcher 是一个用以管理所有的数据流的中央处理器。本质上讲,它是一个回调函数登记库。当action creator提供了新的action给store时,所有的store都会通过登记在库的回调函数来接收action。随着应用变得复杂,dispatcher 的作用也越发重要。它可以通过掌控已注册的回调函数的触发顺序来管理store间的依赖:store可以声明式地等待其他store更新完毕以后再做响应更新。

3.2 Stores

store 包含了应用的状态以及逻辑,它的作用有一点类似于MVC模式的model,但它们管理了多个对象的状态,并不代表像ORM模型那样的单一记录。store既展示了集合model的特性,又展示了特定逻辑域的单一model。

store调用dispatcher的register方法进行注册,并提供一个以action作为参数的回调函数。在回调函数内部有一个switch语句,通过判断action的类型来决定进入哪个钩子函数,并进行相应的更新。store更新之后,便广播一个change事件声明state已变,views便可获得新的state并更新视图。

另外,在stores外面并不能看到store是如何管理数据的,stores对外只暴露getter()方法而不暴露setter()方法。要改变stores只能通过 action creator/dispatcher。

3.3 Views -- Controller-Views

controller-views 处于view分层结构的顶端,将store与view进行 “胶合” :它监听从store广播出来的事件,用store的getter方法获取新的state,然后调用自身的setState()方法让render得以触发。

通常,我们会通过一个对象把整个store的状态传递到视图层,让视图层取得各自所需的状态。这样做将类控制器的行为保留在了分层结构的顶端,尽可能地保持了子视图的纯净,也减少了需要管理的属性。

有时,为了使组件简单,且易于封装,我们需要一个更深入的Controller-Views。但是,它会让引入一个新的、潜在的冲突入口点来破坏单一的更新数据流。因此,在开发时需要权衡一下组件简单化的增益与多个数据更新流的复杂性。后者可能会导致React的重复渲染,调试起来也会比较困难。

3.4 Actions

dispatcher 暴露给我们一个方法,以此可以向store派发一个动作,这个动作称之为action。action的创建被封装在了一个能够被视图的事件处理器所触发的方法内,所以这个方法可以是对用户交互进行的响应(也可以由服务器触发,例如数据的初始化或者服务器数据更新时需要向应用提供数据)。action creator 包含了type与payload等字段,用以描述一个事件以及与更新相关的数据。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249