@H_301_1@本文转载自：众成翻译
译者：iOSDevLog
链接：http://www.zcfy.cc/article/3812
原文：https://www.fullstackreact.com/30-days-of-react/day-18/
@H_
301_1@处理客户端应用中的数据是一项复杂的任务。今天我们正在研究一种处理Facebook提出的复杂数据的
方法，称为 Flux 体系结构。
@H_
301_1@随着应用变得越来越复杂,我们需要更好的数据处理
方法。有了更多的数据,我们将有更多的记录。
@H_
301_1@我们的
代码需要使用新
功能处理更多的数据和应用状态。从异步服务器响应到本地
生成的、不同步的数据,我们不仅要跟踪这些数据,还要将其与视图保持正常的联系。
@H_
301_1@认识到对数据管理的需求,facebook 团队发布了一种处理数据的模式,称为
Flux。
@H_
301_1@今天,我们将看一下Flux体系结构,它是什么以及它存在的原因。
什么是flux
@H_
301_1@Flux是一种用于管理数据如何通过React应用流动的模式。正如我们所看到的,使用React组件的首选
方法是通过从一个父组件向它的子组件传递数据。Flux模式使此模型成为处理数据的默认
方法。
@H_
301_1@在Flux
方法中处理数据有三不同的角色:
- @H_301_1@Dispatcher 派发器
- @H_301_1@Stores 储存
- @H_301_1@Views (our components) 视图层(我们的组件)
@H_
301_1@Flux的主要思想是,有一个单一源 (Stores 储存),他们只能通过触发
actions 更新。这些操作负责
调用派发器,Stores可以
订阅 更改并相应地更新自己的数据。
@H_
301_1@When a dispatch has been triggered,and the store updates,it will emit a change event which the views can rerender accordingly.当发送已触发,并且存储更新时,它将发出一个更改事件,视图可以据此 重新渲染。
@H_
301_1@
@H_
301_1@这似乎没必要这么复杂,但结构使它难以置信地容易推理,我们的数据来自哪里,导致它的变化,如何改变,让我们跟踪特定的
用户流,等等。
@H_
301_1@
Flux 背后的关键理念是:
@H_
301_1@数据流向一个方向,并完全保存在Stores中。
实现
@H_
301_1@虽然我们可以创建我们自己的flux实现,许多已经创建了一些梦幻般的库,我们可以挑选。
@H_301_1@我们深入讨论这个材料关于Flux,使用库,甚至实现我们自己的版本的Flux,最适合我们。
查看 fullstackreact.com
@H_
301_1@它可能是相当激烈的尝试为我们的应用选择
正确 选项。每个人因为不同的原因都有自己的特点,是伟大的。然而,在很大程度上,React社区已经集中在使用另一种称为
Redux的flux工具。
@H_
301_1@Redux是一个小的库,它的设计灵感来自flux模式,但本身不是一个纯粹的flux实现。它提供了相同的一般原则,围绕如何更新我们的应用中的数据,但以略微不同的方式。
@H_
301_1@与Flux不同,Redux不使用派发器,而是使用纯
函数来定义数据变异
函数。它仍然使用
Store（储存）和
Action（动作）,可以直接地被栓到React组件。
@H_
301_1@
3 主要原则的Redux我们将牢记在我们的应用中实现Redux是:
- @H_301_1@使用纯函数进行更新 (in reducers 在归约器中)
- @H_301_1@
state 是只读属性
- @H_301_1@
state是唯一的来源 (一个Redux的应用只有一个Stores 储存 )
@H_
301_1@Redux和Flux的一个大的区别是中间件的概念。Redux
增加了中间件的想法,我们可以使用它来操作我们接收到的操作,无论是进入还是从我们的应用中。几天后我们再详细讨论。
@H_
301_1@在任何情况下,这是很多介绍的flux模式。明天,我们将实际开始移动我们的数据使用Redux。
