5 ms·
Hang on, I use componentWillReceiveProps in just about every large non-function component I build.... I just counted 50 times in one of my applications. and it
by hoodoof 9y ago
Hang on, I use componentWillReceiveProps in just about every large non-function component I build.... I just counted 50 times in one of my applications.
and its going as soon as V17? Too early.
- xnxn 9y agoThe post says the UNSAFE_ versions will continue to work in V17
- a13n 9y agoWhy do you need to use that method so often?
- danabramov 9y agoCurious, what do you use it for?
- hoodoof 9y agoI use it to handle changes in props. For example load something from network, which goes into redux, redux triggers a props update, so then I do something because for example now redux state has changed to say "loaded === true" Is this not the correct function to handle changes in props?
- spicyj 9y agoWhen you see that the props have changed, what do you do? (You said you do "something".) If you are updating the state of that component, that's exactly what the new getDerivedStateFromProps is designed for. If you are doing something else (esp. fetching other data or some other side effect), componentDidUpdate is likely the best place (it receives prevProps as an argument, so you can compare old and new).
- danabramov 9y agoI'd also add that in general we suggest there to be one source of truth for any data. For any particular data, you could put it in Redux -or- in local state, but there is rarely a need to keep it in both. Manually copying things from Redux into local state from `componentWillReceiveProps` (or even with new `getDerivedStateFromProps`) seems unnecessary to me. There are exceptions like rare cases where you want to have a “draft” of some state that can later be “reverted”. But in general you wouldn't want to “sync” state from one source to another.
- hoodoof 9y ago>> When you see that the props have changed, what do you do? "What do I do in componentWillReceiveProps?" It's a good question. Looking through the code I see alot of cases in which I am mapping new props to state, sometimes transforming received network data that is stored in redux, sometimes making a barrier to redirect to a different page if for example some condition has changed. Perhaps these things are relics from before I really came to understand Redux - maybe in most cases I can just directly use props rather than having an intermediate setting of state.
- danabramov 9y ago>sometimes making a barrier to redirect to a different page if for example some condition has changed. That's a side effect. Move that to `componentDidUpdate`: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#side-effects-on-props-change https://reactjs.org/blog/2018/03/27/update-on-async-renderin... >mapping new props to state As I noted in https://news.ycombinator.com/item?id=16711813 https://news.ycombinator.com/item?id=16711813, usually it's not necessary (and complicated your code for nor benefit). For rare cases when it's useful, migrate to `getDerivedStateFromProps`: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#updating-state-based-on-props https://reactjs.org/blog/2018/03/27/update-on-async-renderin...
- brianvaughn 9y agoYou will be able to continue to use this method in version 17. You'll just need to run a codemod [1] to rename it to "UNSAFE_ componentWillReceiveProps". It will otherwise work the same as it always has. We are trying to strike a balance between supporting huge legacy apps- (something Facebook has to do for itself too)- and encouraging safe/bug-free coding practices for future apps. 1: https://github.com/reactjs/rfcs/blob/master/text/0006-static-lifecycle-methods.md#common-problems https://github.com/reactjs/rfcs/blob/master/text/0006-static...