A note about not firing side effects in useState(prev => next) ?

[dxinteractive]

So I ended up doing this by mistake after a wonky merge:

let Foo = (props) => {
    let [bar, setBar] = useState();
    
    let handleClick = () => {
        useState(bar => {
            let newBar = bar + 1;
            props.handleBarChange(newBar); // bad, which isn't surprising
            return newBar;
        });
    };

    return <div onClick={handleClick}>click me</div>;
};

If you fire a side effect such as calling something that sets state in a higher component from a useState updater function, you get the error "Cannot update a component from inside the function body of a different component" (but not always! It seems to depend on internal timing). This definitely seems like a bad idea when you look at it, but I couldn't find any mention in the docs that this is bad.

https://reactjs.org/docs/hooks-reference.html#functional-updates

There is the note about side effects generally on useEffect:

Mutations, subscriptions, timers, logging, and other side effects are not allowed inside the main body of a function component (referred to as React’s render phase)

But this is not in the main body of a function component, doesn't feel like a true side effect as it's still just setting state within React, and doesn't feel like it's in the render phase either.

I initially wanted to comment about this here (react/react#18178), because the general message of that thread was "don't set state of another component in a render method", and I've managed to get this error message without doing that, but the thread is locked. Thanks.

[gaearon]

Updaters generally run in the render phase, while a component is rendering. So doing any side effects there or setting state on other components is definitely a no-no.

[dxinteractive]

Makes sense. I guess the missing piece of info for me was whether a setState call was regarded as occurring in the render phase, or merely triggering a render phase and therefore wasn't part of the render phase itself. Knowing that it's easy to prove that the code up there is a silly thing to do.

While the terms "render phase" and "commit phase" are mentioned in the docs a couple of places, I wasn't able to find anything that clearly said "all these things are in the render phase / all these other things are in the commit phase / and these things cause transitions between phases". The React Component page alludes to it, but only in passing. I did find this diagram which if it's correct seems quite useful http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/

I'd love to see a page in the docs that walks people through that slightly deeper knowledge of how the lifecycle works, which lifecycle methods belong in which phases, and which trigger other phases. I really like how a bunch of the hooks documentation didn't sugar-coat how they worked, they gave a decent description of how hooks work internally so that devs get the right mental model from the start. And honestly React's docs have done a good job of that on a conceptual level with the whole props-go-down, callbacks-go-up thing too.

Feel free to close if you feel like the docs are good enough though, or if the pay off for the time invested in a lifecycle overview / diagram page would not we worth it for how many people would benefit from it. I could very well be in the minority where it comes to wanting to knowing what things truly count as the render phase vs the commit phase. There are 3rd party descriptions around that provide the info it seems.