Any of these sorts of hacks tend to be indicative of something not being structured poorly.
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://beta.reactjs.org/learn/you-might-not-need-an-effect#...
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.
From the original hooks FAQ at time of release:
- 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-...
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.
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.