如何理解 Facebook 的 flux架构 应用架构

来源：蜘蛛抓取(WebSpider) 时间：2016-11-18 04:07 标签： flux架构

摘要：React社区从其他领域（游戏渲染、ClojureScript、函数式编程）偷师学艺结合前端面临的独特问题，提出了一系列解决方案React社区在各方面都推动着前端社区往前进。这对整个社區都是好事

2004年，对于前端社区来说是里程碑式的一年。Gmail横空出世它带来基于前端渲染的原生应用级别的体验，相对于之前的服务端渲染网页可谓提升了一个时代触动了用户的G点。自此前端渲染的网站成为无数开发者追逐的方向。

为了更好地开发前端渲染的“原生級别的”网站包括Backbone和Angular在内的一系列前端框架应运而生，并迅速获得了大规模的采用但是很快地，新的性能和SEO问题也接踵而来几经尝試后，Twitter甚至从前端渲染重回服务器渲染而Strikingly也面对过同样棘手的问题。

2014年React进入我们的视线。让人耳目一新的是对于其他开源框架遇到嘚种种问题，React都自信地给出了解答几乎没有犹豫，我们开始使用React来重构Strikingly若干年后，当我们回望也许会发现，2014年也是前端社区里程碑式的一年

React究竟是什么？Facebook把它简单低调地定义成一个“用来构建UI的JavaScript库”这个定义也许会让我们联想到许多JavaScript模板语言（比如Handlebars和Swig），或者早期的控件库（比如YUI和Dojo）但是React所基于的几个核心概念使它与那些模板和控件库迥然不同。事实上这几个核心概念非常超前已经给整个前端世界带来了冲击性的影响。它们包括：

  1. 组件和基于组件的设计流程；
  2. 虚拟DOM取代物理DOM作为操作对象；

这几条简单的原则放在一起带来了大量的好处：

  1. 前端和后端都能够从React组件渲染页面完全解决了SEO长期困扰JavaScript单页应用的问题；
  2. 我们可以简单直接地写前端测试而完全忘掉DOM依赖；
  3. 組件的封装方式和单向数据流动能够极大地简化前端架构的理解难度。

冯哲锐 CTO 郭达峰在CSDN前端大讲堂（微信公开课）中深度分享React开发实践，并在线与参与者进行深度交流

如何参加CSDN前端大讲堂（微信公开课）？

由于该群目前已超过人数限制所以您首先不得不 扫描下面二维碼，加CSDN编辑陈秋歌为好友然后请她邀请您加入CSDN前端大讲堂微信群，享受高含金量在线公开课与专家讲师在线切磋交流。加好友时请務必注明“申请加入CSDN前端大讲堂”。

同时也欢迎加入CSDN前端交流群2：进行前端技术交流。 

本文选自程序员电子版2015年8月A刊该期更多文章请查看。2000年创刊至今所有文章目录请查看欢迎（含iPad版、Android版、PDF版）。

本文为CSDN原创文章未经允许不得转载，如需转载请联系market#csdn.net(#换成@)

首先 我来解释下flux架构大概解决了什么问题。flux架构是一种在app中处理数据的模式在Facebook，flux架构和React和并驱前行大部分开发者一起使用它们，但是你可以为你自己所用它們的存在是解决了Facebook当期遇到的问题 

这一系列的问题中，最大的Bug莫非新消息通知了当你登录Facebook了，你发现消息栏有提示了你很自然的去查看新消息，事实上并没有新消息这时，提示没有了之后你已经刷了好几分钟好友的动态，新消息提醒又来了你又去查看了，但是还昰没有就这样来回折腾。 

这种循环不仅仅针对用户而言同样也困扰了Facebook团队。他们修复了这个Bug一切都恢复正常。这种正常状态仅仅只會维持一会儿之后又会出现，再又去修复反反复复。Facebook不得不寻找一个更合理的方式完全消除这个Bug 

他们发现潜在的问题存在於程序中数据的流动。

程序中有专门存放数据的models并且会将数传递给view，渲染数据 
用户的交互发生在views，views有时需要根据用户的输入来更新model中嘚数据有时model需要依赖其他model更新。

更重要的是有时这些操作会引发一些级联变化。很难精准预测数据的走向 

事实上使这些数据可能会發生在异步，一个数据的改变可能会引发多个变化基于以上，不便于开发者调式数据流 

解决方案：单向数据流動

一因此Facebook觉定尝试一种单向数据流架构–仅仅只有一个方向。当你插入新数据的时候数据流从头开始进行。这就是flux架构架构

一旦你理解了flux架构，这个图是相当清楚的问题是，如果你从Facebook的文档入手我不认为这个图可以帮助你理解它……这就是这篇文章应该做的。在你嫃正开始搞清楚你怎么做具体的事情之前你应该有一个系统的理解。

在我解释一下它们是如何相互影响之前，先让我只是去給一个快速的文字介绍

第一个角色是行为创造者。它是负责创造行为所以的改变和交互都会经历这一步。无论何时你打算妀变app的状态或者改变一下view你都讲触发一个action。

我把行为创造者比作一个报务员当你访问action creator的时候，它知道了你将要发送什么信息稍后它整理这些数据，方便数据流中其它成员认识这些数据

调度员基本上是一个回调的注册表。这有点像一个电话接线员在电话总机咜保持所有它需要发送操作到stores（商店）的列表。当一个动作来自动作创造者它会来回传递的行动不同的stores。

这是一个同步调用如果你想偠设置stores之间的依赖关系，为了数据更新有个先后顺序你可以让dispatcher用waitFor()为你管理这些顺序。

flux架构 dispatcher与许多其他架构的dispatcher不同不管这个action是什么动作類型，该动作会被发送给所有注册过的商店这意味着stores不只是订阅某一些actions。它监听所有的action并筛选出它所关心和不关心的。

接下来就是store了store保存了程序中所有的状态。

我把store比作为一个过度控制人员所有状态的改变都必须亲自由它处理。你并不能直接请求并改变状态在store内沒有 setter。为了请求状态改变你必须得遵循一些列流程。。你必须通过acion creator 和dispatcher pipeline提交一个action

正如我上面提到的，如果store注册到l了dispatcher所有操作将被发送给它。在store内通常有一个switch语句查看操作类型，以决定这个store是否不关心这个action若该store不关心这个action，它会找出在该action的基础上与之相对应的操作改变和更新状态。

一旦store已经完成了状态的改变它将emit(发射)一个change event（变化事件）。它将通知controller view某个状态已经改变。

view负责获取状态为用户渲染数据同时接受用户的输入。

View负责展示数据在程序中它感知不到任何数据的变化，它就知道有数据传递给它了它得以合理的方式输出數据（以html的形式）。

Control view就介于store与view之间store告诉它某个状态什么时候改变了。它收集了新的状态然后将已经已经更新的状态全部传递给view.

让我们来看看它们是如何一起运作的。

首先需要设置一下：程序初始化哪些action只发生一次

4.controllre view 也会让store随时保持警惕，因为状态改變了它就会收到通知。

一旦初始化完毕程序就可以接受用户的输入了。让我们通过用户的的请求触发一个action

我们将随着用户的茭互开始一个数据流动。

为了方便理解主要的英文名词嘟没有翻译。比如：dispatcher（调度者）、 store（仓库）、view（视图）

flux架构是Facebook用来构建用户端的web应用的应用程序体系架构它通过利用数据的单向流动为React嘚可复用的视图组件提供了补充。相比于形式化的框架它更像是一个架构思想不需要太多新的代码你就可以马上使用flux架构构建你的应用。

creators - dispatcher辅助方法 - 一个被用来提供描述应用所有可能存在的改变的语义化的API把它理解为flux架构更新闭环的第四个组成部分可以帮助你更好的理解咜。

flux架构使用单向的数据流动来避开/p/c

我要回帖

更多关于 flux架构 的文章

 

随机推荐