3 ms·
Agreed, but it's a pretty big footgun because `useEffect` is often the seemingly easiest way to do the things you list. I've had similar conversations many tim
by jasonkillian 4y ago
Agreed, but it's a pretty big footgun because `useEffect` is often the seemingly easiest way to do the things you list.
I've had similar conversations many times with coworkers before when they were using `useEffect` to keep a state value in sync with a prop. The officially-recommended alternative of manually storing and updating an extra piece of state containing the previous prop value is cumbersome and also had ways it can go wrong. So, since `useEffect` works well enough in most cases and is easier, often the code just sticks with that method. I'm not entirely sure what's really best all tradeoffs considered, but it definitely illustrates how rough edges often pop up in hook-based React.
- nwienert 4y agoYou don’t have to store the previous, you can just do an if != right in the render function and call setState there. That’s something I learned from the new beta docs.
- aidos 4y agoCan you point to that in the docs? Calling setState during render sounds like a fine way to get infinite loops. Any of these sorts of hacks tend to be indicative of something not being structured poorly.
- mynameisvlad 4y agoIsn’t it also explicitly discouraged with a warning because of how bad it could be? The React docs are very clear on this: > The render() function should be pure, meaning that it does not modify component state, it returns the same result each time it’s invoked, and it does not directly interact with the browser. https://reactjs.org/docs/react-component.html#render https://reactjs.org/docs/react-component.html#render
- nwienert 4y agoIt’s recommended now: https://beta.reactjs.org/learn/you-might-not-need-an-effect#adjusting-some-state-when-a-prop-changes https://beta.reactjs.org/learn/you-might-not-need-an-effect#...
- aidos 4y agoInteresting. Thanks for following up.
- mynameisvlad 4y agoThat’s such a weird 180 on their part considering how explicit they have been about it. I guess they did a bunch of work to make the case work and are confident about it, but it just seems like such a weird decision considering they’ve been adamantly telling their devs not to do this for years.
- acemarke 4y agoCalling `setState` while rendering has been a legitimate thing to do since hooks first came out, but _only_ in one specific scenario / usage pattern. From the original hooks FAQ at time of release: - https://reactjs.org/docs/hooks-faq.html#how-do-i-implement-getderivedstatefromprops https://reactjs.org/docs/hooks-faq.html#how-do-i-implement-g... I talked about the reasoning / behavior for this in my React rendering guide: - https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/#setting-state-while-rendering https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
- mynameisvlad 4y agoThat still doesn’t change my comment. It used to explicitly be a thing you must not do for years, it’s weird to go straight 180 on something you actively warn developers not to do. If it wasn’t well documented in the past, then that’s reasonable, but actively spitting out console warnings and explicit documentation warning against it is just going to mean that anyone who isn’t new to react is going to be extremely weary about it.