@@ -5,7 +5,7 @@ author: [bvaughn]
5
5
6
6
一年多来,React 团队一直致力于实现异步渲染。上个月,在 JSConf 冰岛的演讲中,[ Dan 揭晓了一些令人兴奋的新的异步渲染可能] ( /blog/2018/03/01/sneak-peek-beyond-react-16.html ) 。现在,我们希望与你分享我们在使用这些功能时学到的一些经验教训,以及一些帮助你在组件启动时准备异步渲染的方法。
7
7
8
- 我们学到的最重要的经验是,一些遗留的组件生命周期往往会造成不安全的编码实践 ,它们是:
8
+ 我们学到的最重要的经验是,一些过时的组件生命周期往往会造成不安全的编码实践 ,它们是:
9
9
10
10
* ` componentWillMount `
11
11
* ` componentWillReceiveProps `
@@ -21,13 +21,13 @@ author: [bvaughn]
21
21
* ** 未来 16.x 版本** :为 ` componentWillMount ` 、` componentWillReceiveProps ` 和 ` componentWillUpdate ` 启用废弃告警。(旧的生命周期名称和新的别名都将在这个版本中工作,但是旧的名称在开发模式下会产生一个警告。)
22
22
* ** 17.0** :删除 ` componentWillMount ` 、` componentWillReceiveProps ` 和 ` componentWillUpdate ` 。(在此版本之后,只有新的 "UNSAFE_ " 生命周期名称可以使用。)
23
23
24
- ** 注意,如果你是 React 应用程序开发人员,则无需对遗留方法执行任何操作 。即将发布的 16.3 版本的主要目的是使开源项目维护人员能够在任何废弃警告之前更新他们的库。在未来的 16.x 版本发布之前,不会启用这些警告。**
24
+ ** 注意,如果你是 React 应用程序开发人员,则无需对这些过时的方法执行任何操作 。即将发布的 16.3 版本的主要目的是使开源项目维护人员能够在任何废弃警告之前更新他们的库。在未来的 16.x 版本发布之前,不会启用这些警告。**
25
25
26
26
我们在 Facebook 上维护了超过 50,000 个 React 组件,我们不打算立即重写它们。我们知道迁移需要时间。我们将与 React 社区中的每个人一起采取逐步迁移的方式。
27
27
28
28
---
29
29
30
- ## 迁移遗留的生命周期 {#migrating-from-legacy-lifecycles}
30
+ ## 迁移过时的生命周期 {#migrating-from-legacy-lifecycles}
31
31
32
32
如果你想开始使用 React 16.3 中引入的新组件 API(或者如果你是维护人员,希望提前更新你的库),下面是一些示例,我们希望它们将帮助你开始以不同的方式思考组件。随着时间的推移,我们计划在文档中添加额外的“方法”,来说明如何以避免有问题的生命周期的方式执行常见任务。
33
33
@@ -41,7 +41,7 @@ author: [bvaughn]
41
41
42
42
新的静态 ` getDerivedStateFromProps ` 生命周期方法在组件实例化之后以及重新渲染之前调用。它可以返回一个对象来更新 ` state ` ,或者返回 ` null ` 来表示新的 ` props ` 不需要任何 ` state ` 的更新。
43
43
44
- 与 ` componentDidUpdate ` 一起,这个新的生命周期涵盖遗留的 ` componentWillReceiveProps ` 的所有用例。
44
+ 与 ` componentDidUpdate ` 一起,这个新的生命周期涵盖过时的 ` componentWillReceiveProps ` 的所有用例。
45
45
46
46
> 注意:
47
47
>
@@ -53,7 +53,7 @@ author: [bvaughn]
53
53
54
54
新的 ` getSnapshotBeforeUpdate ` 生命周期方法在更新之前(如:更新 DOM 之前)被调用。此生命周期的返回值将作为第三个参数传递给 ` componentDidUpdate ` 。(通常不需要,但在重新渲染过程中手动保留滚动位置等情况下非常有用。)
55
55
56
- 与 ` componentDidUpdate ` 一起,这个新的生命周期涵盖遗留的 ` componentWillUpdate ` 的所有用例。
56
+ 与 ` componentDidUpdate ` 一起,这个新的生命周期涵盖过时的 ` componentWillUpdate ` 的所有用例。
57
57
58
58
你可以[ 在这个 gist] ( https://gist.github.com/gaearon/88634d27abbc4feeb40a698f760f3264 ) 中找到他们的类型签名。
59
59
@@ -62,7 +62,7 @@ author: [bvaughn]
62
62
## 示例 {#examples}
63
63
- [ 初始化 state] ( #initializing-state )
64
64
- [ 获取外部数据] ( #fetching-external-data )
65
- - [ 添加事件侦听器 (或订阅)] ( #adding-event-listeners-or-subscriptions )
65
+ - [ 添加事件监听器 (或订阅)] ( #adding-event-listeners-or-subscriptions )
66
66
- [ 基于 props 更新 ` state ` ] ( #updating-state-based-on-props )
67
67
- [ 调用外部回调] ( #invoking-external-callbacks )
68
68
- [ props 更新的副作用] ( #side-effects-on-props-change )
@@ -83,7 +83,7 @@ author: [bvaughn]
83
83
84
84
### 获取外部数据 {#fetching-external-data}
85
85
86
- 以下是使用 ` componentWillMount ` 获取外部数据的示例 :
86
+ 以下是使用 ` componentWillMount ` 获取外部数据的组件的示例 :
87
87
` embed:update-on-async-rendering/fetching-external-data-before.js `
88
88
89
89
上述代码对于服务器渲染(不使用外部数据)和即将推出的异步渲染模式(可能多次启动请求)都存在问题。
@@ -97,11 +97,11 @@ author: [bvaughn]
97
97
>
98
98
> 一些高级用例(如:Relay 库)可能尝试提前获取异步数据。[ 这里] ( https://gist.github.com/bvaughn/89700e525ff423a75ffb63b1b1e30a8f ) 提供了一个如何实现的示例。
99
99
>
100
- > 从长远来看,在 React 组件中获取数据的标准方法应该基于 “suspense” API [ 在冰岛 JSConf 引入 ] ( /blog/2018/03/01/sneak-peek-beyond-react-16.html ) 。无论是简单的数据获取解决方案,还是像 Apollo 和 Relay 这样的库,都可以在内部使用它。它比上面的任何一个解决方案都要简洁,但是不会在 16.3 版本发布之前完成。
100
+ > 从长远来看,在 React 组件中获取数据的标准方法应该基于 “suspense” API [ 在冰岛 JSConf 提出 ] ( /blog/2018/03/01/sneak-peek-beyond-react-16.html ) 。无论是简单的数据获取解决方案,还是像 Apollo 和 Relay 这样的库,都可以在内部使用它。它比上面的任何一个解决方案都要简洁,但是不会在 16.3 版本发布之前完成。
101
101
>
102
- > 当支持服务器渲染时,需要同步获取数据 – ` componentWillMount ` 经常用于此目的,也可以用构造函数替代。即将推出的 suspense API 将使异步数据获取对于客户端和服务器渲染都是完全有可能的。
102
+ > 当支持服务器渲染时,需要同步获取数据—— ` componentWillMount ` 经常用于此目的,也可以用构造函数替代。即将推出的 suspense API 将使异步数据获取对于客户端和服务器渲染都是完全有可能的。
103
103
104
- ### 添加事件侦听器 (或订阅) {#adding-event-listeners-or-subscriptions}
104
+ ### 添加事件监听器 (或订阅) {#adding-event-listeners-or-subscriptions}
105
105
106
106
下面是一个示例,在组件挂载时订阅了外部事件:
107
107
` embed:update-on-async-rendering/adding-event-listeners-before.js `
@@ -129,7 +129,7 @@ author: [bvaughn]
129
129
>
130
130
> 旧的 ` componentWillReceiveProps ` 和新的 ` getDerivedStateFromProps ` 方法都会给组件增加明显的复杂性。这通常会导致 [ bug] ( /blog/2018/06/07/you-probably-dont-need-derived-state.html#common-bugs-when-using-derived-state ) 。考虑 ** [ 派生 state 的简单替代方法] ( /blog/2018/06/07/you-probably-dont-need-derived-state.html ) ** 使组件可预测且可维护。
131
131
132
- 这是一个示例,组件使用遗留的 ` componentWillReceiveProps ` 生命周期基于新的 ` props ` 更新 ` state ` :
132
+ 这是一个示例,组件使用过时的 ` componentWillReceiveProps ` 生命周期基于新的 ` props ` 更新 ` state ` :
133
133
` embed:update-on-async-rendering/updating-state-from-props-before.js `
134
134
135
135
尽管上面的代码本身没有问题,但是 ` componentWillReceiveProps ` 生命周期经常被误用,_ 会_ 产生问题。因此,该方法将被废弃。
@@ -177,7 +177,7 @@ author: [bvaughn]
177
177
178
178
> 注意
179
179
>
180
- > 如果你正在使用支持取消的 HTTP 库,例如 [ axios] ( https://www.npmjs.com/package/axios ) 那么在卸载时取消正在进行的请求非常简单。对于原生的 Promises ,你可以使用类似[ 此处所示] ( https://gist.github.com/bvaughn/982ab689a41097237f6e9860db7ca8d6 ) 的方法。
180
+ > 如果你正在使用支持取消的 HTTP 库,例如 [ axios] ( https://www.npmjs.com/package/axios ) 那么在卸载时取消正在进行的请求非常简单。对于原生的 Promise ,你可以使用类似[ 此处所示] ( https://gist.github.com/bvaughn/982ab689a41097237f6e9860db7ca8d6 ) 的方法。
181
181
182
182
### 更新前读取 DOM 属性 {#reading-dom-properties-before-an-update}
183
183
@@ -198,7 +198,7 @@ author: [bvaughn]
198
198
199
199
## 其他场景 {#other-scenarios}
200
200
201
- 尽管我们试图在这篇博文中涵盖最常见的用例,但是我们意识到依然可能会遗漏其中的一些用例。如果你正在以本博文未涵盖的方式使用 ` componentWillMount ` 、` componentWillUpdate ` 或者 ` componentWillReceiveProps ` ,并且不确定如何迁移这些遗留的生命周期 ,请[ 根据我们的文档提交一个新的 issue] ( https://github.com/reactjs/reactjs.org/issues/new ) ,附上你的代码示例,并提供尽可能多的背景信息。当出现新的替代用例时,我们将用它们更新此文档。
201
+ 尽管我们试图在这篇博文中涵盖最常见的用例,但是我们意识到依然可能会遗漏其中的一些用例。如果你正在以本博文未涵盖的方式使用 ` componentWillMount ` 、` componentWillUpdate ` 或者 ` componentWillReceiveProps ` ,并且不确定如何迁移这些过时的生命周期 ,请[ 根据我们的文档提交一个新的 issue] ( https://github.com/reactjs/reactjs.org/issues/new ) ,附上你的代码示例,并提供尽可能多的背景信息。当出现新的替代用例时,我们将用它们更新此文档。
202
202
203
203
## 开源项目维护者 {#open-source-project-maintainers}
204
204
0 commit comments