You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/blog/2018-05-23-react-v-16-4.md
+3-11Lines changed: 3 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,17 +11,9 @@ TODO (@bvaughn)
11
11
12
12
## Bugfix for `getDerivedStateFromProps`
13
13
14
-
`getDerivedStateFromProps` is now called when either props or state change. Previously, it would not fire for state-only changes (similar to `componentWillReceiveProps`). This was an oversight in the initial implementation that has now been corrected.
14
+
`getDerivedStateFromProps` is now called every time a component is rendered, regardless of the cause of the update. Previously, it was only called if the component was re-rendered by its parent; it would not fire as the result of a local `setState`. This was an oversight in the initial implementation that has now been corrected. The previous behavior was more similar to how `componentWillReceiveProps` works, but the improved behavior ensures compatibility with React's upcoming asynchronous rendering mode.
15
15
16
-
### Why?
17
-
18
-
`getDerivedStateFromProps` was designed as an alternative to `componentWillReceiveProps` that is compatible with async rendering. Because props in React are derived from state that lives in a parent component, APIs like `componentWillReceiveProps` that are modelled around "prop change events" don't really make sense, and can't be reliably implemented in React's upcoming asynchronous rendering mode.
19
-
20
-
Another way to think about it is that `getDerivedStateFromProps(props, state)` accepts both props and state as input, so we need to re-calculate the derived state whenever either of the inputs change.
21
-
22
-
### How Does This Affect Me?
23
-
24
-
**Most likely, this doesn't require any changes to your components**. The rare cases where it does matter usually fall into one of two categories:
16
+
**Most likely, this doesn't require any changes to your components**. The rare cases where it does matter fall into one of two categories:
25
17
26
18
### Avoid Side Effects in `getDerivedStateFromProps`
27
19
@@ -31,7 +23,7 @@ Side effects in `getDerivedStateFromProps` were already disallowed, but since it
31
23
32
24
### Compare Incoming Props to Previous Props When Computing Controlled Values
33
25
34
-
The following code will not work. It assumes `getDerivedStateFromProps` only fires on prop changes. But since it now fires for state changes, too, local updates to the controlled value will be ignored, since the props version always overrides it.
26
+
The following code assumes `getDerivedStateFromProps` only fires on prop changes. But since it now fires for state changes, too, local updates to the controlled value will be ignored, since the props version always overrides it.
0 commit comments