React Native 第七天

FLUX架构 如何使用

Flux 是 Facebook 定义的一种单向数据流架构，设计思想如下，单向数据流是flux的核心

（flux就像水流一旦流出不能回头，有别于angularJs的双向绑定）

 

Flux 避免使用 MVC 有利于单向数据流。当用户和react-views交互时，view会通过一个中央Dispatcher传播一个动作

给保持程序数据安定业务逻辑的各个store，更有所有受影响的视图，它允许store发送不指定在state间如何转换视图。

 

我们开始着手正确处理获取的数据，比如，我们想要展示消息线程未读数，而另一个视图显示一个未读消息高亮显示的

线程列表，这个用MVC是难于控制的----标记单独一个线程是已读将会更新线程model，也需要更新未读数model，这些依赖项

和级联更新通常发生大型MVC应用程序中，这将会导致数据流交织和不可预测的结果。

 

Control 和 store 反转：stores接受更新并根据需要对他们进行协调,而不是依赖外部的一些一致的方法来更新数据

Store以外的任何事物，都不会知道洞察store里面是如何管理内部数据的，有助于保持对关注点的明确分离，Store没有直接setter

方法，而是只有一种方法获取数据导入到自己内部—在dispatcher中注册的回掉

 

 

结构和数据流

数据在Flux架构的程序中式单向流动的。

单向数据流式Flux模式的核心，上图式Flux程序的基本意图模型，Dispatcher，stores，Views是有着输入和输出区分独立的节点。

Action是包含新数据和一个标识属性的简单对象。Views会引发新的action作为用户交互响应在系统中传播。

所有的数据流都会通过Dispatcher中心枢纽，Actions在一个action 制造方法中被提供给Dispatcher，最常见的来源是用户与

视图交互，然后Dispatcher调用store注册的回掉函数分发action给store。在其注册的回掉函数中，store对与所维护的状态

相关的任何actions都作出响应。Store会发送一个更变事件去提醒controller-view数据层发生了变化。Controller-view层监听这些事件

并且获取数据然后调用自己的setstate方法，重新绘制页面。

这种结构使我们能够很容易地对我们的应用程序进行推理, 这种方式可以让人联想到功能性的反应性编程, 或者更具体地说是数据流编

程或基于流的编程, 其中数据通过一个单一的方向流向应用程序--没有双向绑定。应用程序状态仅在stores中维护, 从而使应用程序的

不同部分保持高度的解耦。在stores之间发生依赖关系时, 它们保持在严格的层次结构中, 同步更新由Dispatcher程序管理。

 

我们发现双向数据绑定导致了级联更新, 在这种情况下, 更改一个对象导致另一个对象发生更改, 这也可能触发更多更新。随着应用程序的增长,

这些级联更新使得很难预测由于一个用户交互的结果会发生什么变化。当更新只能在单个回合中更改数据时, 整个系统就变得更加可预测。

 

 

单个Dispatcher

Dispatcher是在flux程序中管理数据流的中心枢纽，它基本上是一个回掉函数到store的注册表，自己没有真正意识。它是分发action给store的一个

简单装置，任何一个store都会注册它自己并且提供callback，当一个action制造器为dispacther提供了一个新的action时，程序中所有的stores通过

注册表中的回掉函数接收到这个action

 

随着程序的增长，Dispatcher变的更加重要，因为它可用于通过以特定顺序调用已注册的回调来管理stores之间的依赖关系。Stores

可以以声明的方式等待其他stores的完成，然后相应的更新自己。

Stores

stores包含应用程序状态和逻辑。他们的角色与传统 MVC 中的model有点相似, 但它们管理许多对象的状态-它们并

不代表 ORM 模型所做的单个数据记录。它们也不像Backbone的集合。除了简单管理 ORM 样式对象的集合之外,

store还管理应用程序中特定域的应用程序状态。

 

例如, Facebook 的回望视频编辑器使用了一个 TimeStore, 它跟踪播放时间位置和回放状态。另一方面,

同一应用程序的 ImageStore 跟踪图像的集合。我们的 TodoMVC 示例中的 TodoStore 类似于它

管理要执行的项目的集合。商店展示了模型集合和逻辑域的单一模型的特征。

 

如上所述,store与dispacther一起注册, 并为其提供回调。此回调将作为参数接收该actions。在store的注册回调中,

基于该actions类型的开关语句用于解释actions, 并为stores的内部方法提供适当的挂钩。这允许actions通过Dispatcher程序导

致对stores状态的更新。更新stores区后, 它们会广播一个事件, 声明其状态已更改, 因此视图可以查询新状态

并进行更新。

 

 

Views and Controller-Views

ReactProvider为视图层提供了一种可组合和自由重新可呈现的视图。靠近嵌套视图层次结构的顶部, 一种特殊类型的视图侦听由它所依赖的stores所广播的事件。

我们称之为控制器视图, 因为它提供了胶水代码来从stores区获取数据, 并将这些数据传递到其子代链中。我们可能有一个Controller-Views管理页面的任何重要部分。

 

当它从store接收事件时, 它首先请求通过store的公共 getter 方法所需的新数据。然后调用它自己的 setState () 或 forceUpdate () 方法,

导致其render () 方法和其所有子代的render () 方法运行。

 

我们经常将整个store状态从单个对象的视图链中传递下来, 允许不同的后代使用他们需要的内容。除了在层次结构的顶部保持类似于控制器的行为,

从而使我们的子代视图尽可能地保持功能上的纯净, 在单个对象中传递stores的整个状态也有减少道具数量的效果, 我们需要管理。

 

有时, 我们可能需要在层次结构中更深层次地添加更多的Controller-Views, 以保持组件的简单。这可能有助于我们更好地封装与特定数据域

相关的层次结构的一部分。但是, 请注意, 控Controller-Views在更深层次结构中可以通过引入一个新的、潜在冲突的数据流入口点来违反数据的奇异流。

在决定是否添加深层控制器视图时, 应平衡较简单组件的增益与多个数据更新在不同点上流入层次结构的复杂性。这些多数据更新可能会导致奇数效果,

而响应的渲染方法通过不同控制器视图的更新重复调用, 可能会增加调试的难度。

 

 

Actions 

Dispatcher公开了一种方法, 它允许我们触发对stores的Dispatcher, 并包含我们称为actions的数据负载。actions的创建可能被包装成一个语义帮助器方法,

将该actions发送到Dispatcher程序。例如, 我们可能希望在 "要执行的列表" 应用程序中更改要执行的项的文本。我们将创建一个功能签名,

如 updateText (todoId,new-Text) 在我们的 TodoActions 模块的行动。此方法可以从我们的视图的事件处理程序中调用, 因此我们可以调用它

来响应用户交互。此actions创建器方法还向actions添加类型, 以便在stores区中解释actions时, 它可以适当地响应。在我们的示例中,

此类型可能被命名为 TODO_UPDATE_TEXT 之类的内容。

 

actions也可能来自其他位置, 如服务器。例如, 在数据初始化过程中会发生这种情况。当服务器返回错误代码或服务器有更新提供给应用程序时,

也可能发生这种情况。