Skip to content

Commit 6d42fff

Browse files
committed
Tweak gDSFP section
1 parent 8436ed5 commit 6d42fff

File tree

1 file changed

+3
-11
lines changed

1 file changed

+3
-11
lines changed

content/blog/2018-05-23-react-v-16-4.md

Lines changed: 3 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -11,17 +11,9 @@ TODO (@bvaughn)
1111

1212
## Bugfix for `getDerivedStateFromProps`
1313

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.
1515

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:
2517

2618
### Avoid Side Effects in `getDerivedStateFromProps`
2719

@@ -31,7 +23,7 @@ Side effects in `getDerivedStateFromProps` were already disallowed, but since it
3123

3224
### Compare Incoming Props to Previous Props When Computing Controlled Values
3325

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.
3527

3628
```js
3729
static getDerivedStateFromProps(props, state) {

0 commit comments

Comments
 (0)