How to handle componentWillReceiveProps deprecation
koulmomo opened this issue · comments
Type of issue
Question/Discussion
Description
componentWillReceiveProps
is soon going to be deprecated in future versions of react.
The new recommendation for making side-effects when there is a difference between current + previous props is to do so in componentDidUpdate
(see: https://reactjs.org/docs/react-component.html#componentdidupdate)
When react enables async rendering in future releases of react, this will break lifecycle methods into "render" phase and "commit" phase. Methods in the "render" phase (includes componentWillReceiveProps
) are meant to be side-effect free as they might be called multiple times.
componentDidMount
and componentDidUpdate
are called in the "commit" phase and are the recommended place for side-effects (includes network calls). see: https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects
twitter thread with more context: https://twitter.com/ken_wheeler/status/983022255746768897?s=20
Current behavior
opts.componentWillReceiveProps = true
causes sideEffect
to be called each time we receive new props.
Expected behavior
I think at a bare minimum prepared
should support a new opts.componentDidUpdate
that behaves the same as componentWillReceiveProps
. Adding this feature would be BC and allow people to switch to using that option for the same use case as opts.componentWillReceiveProps
was supposed to address.
At some point this library needs to drop support for opts.componentWillReceiveProps
as it is currently implemented, I see 2 options in this case:
- Still support
opts.componentWillReceiveProps
option but have the underlying implementation callprepare
incomponentDidUpdate
. ie incomponentDidUpdate
callsideEffect
ifopts.componentDidUpdate || opts.componentWillReceiveProps
This allows a new version to be published without needing a major version bump.
- Completely drop support for
opts.componentWillReceiveProps
and bump major.