赵走x博客
网站访问量:151472
首页
书籍
软件
工具
古诗词
搜索
登录
49、Flux:理念、回顾Whinepad
48、lint、Flow、测试与复验:测试
47、lint、Flow、测试与复验:Flow
46、lint、Flow、测试与复验:ESLint
45、lint、Flow、测试与复验:package.json
44、构建实例应用:<Whinepad>
43、构建实例应用:应用配置
43、构建实例应用:<Excel>:改进的新版本
42、构建实例应用:组件:对话框
41、构建实例应用:组件:Actions
39、构建实例应用:表单:Form
38、构建实例应用:表单:<FormInput>“工厂组件”
37、构建实例应用:表单:Rating组件
36、构建实例应用:表单:Suggest
35、构建实例应用:Button组件
34、构建实例应用:组件
33、构建实例应用:Whinepad v.0.0.1
32、发布
31、开始构建
30、安装必备工具
29、为应用开发做准备:一个模板应用
28、JSX 和表单
27、JSX 和HTML 的区别
26、在JSX 中返回多个节点
25、展开属性
24、HTML 实体
23、JSX入门
22、Excel:一个出色的表格组件:下载表格数据
21、Excel:一个出色的表格组件:即时回放
20、Excel:一个出色的表格组件:搜索
19、Excel:一个出色的表格组件:编辑数据
18、Excel:一个出色的表格组件:排序
17、Excel:一个出色的表格组件
16、 PureRenderMixin
15、 性能优化:避免组件更新
14、 生命周期示例:使用子组件
13、组件生命周期示例:使用mixin
12、组件:生命周期方法
11、中途改变属性
10、从外部访问组件
9、在初始化state 时使用props:一种反模式
8、 props 与state
7、关于DOM 事件的说明
6、组件:带状态的文本框组件
5、组件的state
4、组件的propTypes
3、组件的属性
2、组件的基础
1、Hello World
50、Flux:Store
49、Flux:理念、回顾Whinepad
资源编号:76103
书籍
React快速上手开发
热度:113
最后一章将介绍Flux(https://facebook.github.io/flux/ )。Flux 是管理组件间通信的另外一种方式,同时也可以用于管理整个应用的数据流。目前我们已经知道如何把属性从父组件传递到子组件,从而进行组件间通信并监听子组件发生的变化(比如通过onDataChange)。
最后一章将介绍Flux(https://facebook.github.io/flux/ )。Flux 是管理组件间通信的另外一种方式,同时也可以用于管理整个应用的数据流。目前我们已经知道如何把属性从父组件传递到子组件,从而进行组件间通信并监听子组件发生的变化(比如通过onDataChange)。 然而通过这种方式传递属性时,你可能会遇到一个组件需要接收很多属性的情况。这就使得组件的测试变得难以进行,因为属性的组合排列情况非常多,难以验证所有的情况能否正常工作。 此外,在某些场景中,你还需要把属性像“管道”般从父组件传递到子组件、第三级组件、第四级组件……然而这种工作往往是重复的(本质上是不良实践)、混乱的,并且会让阅读代码的人的精神负担更大(有太多事情需要同时跟踪)。 Flux 就是一种可以帮助你克服这些障碍的方式,并让你在管理应用的数据流动时保持头脑清晰。与其说Flux 是一个代码库,不如说它是一种组织(架构)应用数据的思想。毕竟在大部分情况下,数据都是非常重要的。用户可能会使用你的应用管理他们的钱、邮件、照片等。如果应用界面有点粗糙,用户也许还能忍受;但应用在任何情况下都应该能正常处理数据,不能让用户产生疑惑(“刚才我到底有没有成功支付30 美元?”)。 目前,基于Flux 的思想已经衍生出许多版本的开源实现,但本章不会逐一讨论这些实现,而是将尝试自己实现一个Flux 架构。一旦你掌握其思想(并确信Flux 能给你带来便利),就可以深入探究这些开源实现并从中选取一种适合实际开发的方案,也可以持续完善自己的方案。 # 1、理念 在Flux 的理念中,应用的核心就是数据。数据存储于Store 中。你的React 组件(View,视图)从Store 中读取数据并进行渲染。用户与应用之间的交互行为会产生Action(比如点击按钮)。Action 会导致Store 中的数据发生变化,进而影响View。这个循环一直持续进行(如图8-1 所示)。在循环中,数据流动是单向的(unidirectional)。这种单向数据流的优点是更容易进行跟踪、推理与调试。  图8-1:单向数据流 在上述架构的基础之上,还有一些变种与延伸版本,包括更多Action、多重Store 以及Dispatcher 等。在深入解释这些新概念之前,我们先阅读一部分代码。 # 2、回顾Whinepad 在Whinepad 应用中,顶层的React 组件称为`
`,其创建方式如下: ```
组件负责构成
组件:
``` 首先,描述应用所需数据的schema 对象从`
` 组件(像管道般)传递到`
` 组件中(接下来再传递到`
` 组件)。这种方式显得有些重复和纵向模式化。假如你还需要管道式地传递几个类似的属性呢?这样下去,组件表面(surface)就会变得过于庞大,且毫无益处。 上文提及的“表面”指的是一个组件接收的所有属性,通常被用作“API”与“函数签名”的同义词。在程序设计中,应当保持表面最小化。一个函数若接收多达十个参数,会比接收两个(或零个)参数更难以使用、调试与测试。 虽然schema 对象是按照原样传递的,但是数据看似并非如此。`
` 组件接收到initialData 属性后,会对数据进行某些修改再传递给`
` 组件(传递的属性是this.state.data 而不是this.props.initialData)。这里会产生两个问题:如果新的数据不同于原有数据,会发生什么?当提及最新的数据时,到底哪个组件拥有“单一数据源”? 在上一章的实现中,虽然顶层`
` 组件确实包含了最新的数据,但这并没有明确为什么UI 组件(React 是完全和UI 相关的)应该掌握数据的来源。 接下来介绍如何把这项工作移交给Store 进行处理。