Bug: in <StrictMode>, useEffect cleanup is called for the second mount, not the first one about react

[parthnegi21]

The issue you're encountering relates to React's Strict Mode, which intentionally triggers certain lifecycle methods (including useEffect cleanups) twice to help developers identify potential side effects in their components. This is particularly relevant in React 18 and newer versions.

Explanation
Strict Mode in React 18: When you use StrictMode in React, it intentionally unmounts and remounts components to detect side effects. This means that useEffect cleanups may be triggered more than once, even if the component hasn't been visibly removed from the UI.

Double Rendering: In your example, the first useEffect cleanup (clean counter 0) happens, but before the cleanup is logged, React immediately triggers another render of the component, assigning a new counter value (counter 1). However, the cleanup log shows clean counter 1 because React has already moved on to the next render cycle.

Expected Behavior in Strict Mode
Given the intentional behavior of Strict Mode:

The initial render (counter 0) occurs.
React triggers a cleanup, but since the component re-renders immediately, the counter state increments to 1.
The cleanup log shows clean counter 1 because React is now dealing with the most recent state.
How to Handle It
If you want to observe the cleanup of the first render, you might consider disabling Strict Mode or understanding that this behavior is a part of React's effort to make components more resilient. React's double invocation of certain lifecycle methods (including useEffect cleanups) is designed to catch potential issues in components.

[ivstas]

@gianlucadifrancesco @LoganDark damn guys you were right. The example with counter was misleading.
I rewrote it without global variable and the order is correct: https://playcode.io/1994448

function useSecondsSinceMount() {
  const [seconds, setSeconds] = useState(0);
  const [intervalId, setIntervalId] = useState(null)

  useEffect(() => {
    const id = setInterval(() => {
      setSeconds((current) => current + 1);
    }, 1000);

    console.log("set interval", id);
    setIntervalId(id)

    return () => {
      console.log("clean up interval", id);
      clearInterval(id);
    };
  }, []);

  return [seconds, intervalId];
}

export default function App() {
  const [seconds, intervalId] = useSecondsSinceMount();

  return (
    <div className="App">
      <h2>Seconds since component mount: {seconds}</h2>
      {intervalId && (
        <h3>Used interval: {intervalId}</h3>
      )}
    </div>
  );
}

from react.

[ivstas]

@parthnegi21 did you just put the reported bug into ChatGPT to write this answer?

[parthnegi21]

Yes 🥲🥲 new to contribution, didn't know much abut contribution..

[VDXD]

Hello, so in your code you are using useEffect but i notice that you are not using any clean up function in your useEffect and you are also not using any dependencies array i mean i don't think it any use in that code but use clean up function in your useEffect block and you are also using strict mode which render you app component twice to find any bug and when your code executes for second time the counter stays 1 cause it was 1 in first render,

I hope i didn't complex it out sorry if i did but use clean up function in your useEffect block of code that might fix it

[ivstas]

@VDXD - the only thing I do in useEffect is return a cleanup function. For dependency array - my fault, thank you for pointing this out. I have fixed the code example in issue as well as playground link.
However, this doesn't change the behavior - it still unmounts the second counter.

[VDXD]

@ivstas i'm happy that i was able to help you in any way and about return function i thought it was a main function which we give to useEffect sorry about that and i tried lots of solution but nothing seems to works but you can try state in app component and also don't use chatGPT that guy knows nothing about it XD

thank you!

[gianlucadifrancesco]

@ivstas I think this is because React runs the whole App twice before running the first useEffect, therefore you're calling globalCounter++ twice before the first cleanup is called (consequently, counter is 1 at that point).

I've written a reproduction with some detailed logs, and also added a useEffect in App to more understand the behaviour.

Here's the whole timeline:

1. Render useCounter (no useEffect) -> returns 0.
2. Render App (no useEffect) -> current counter 0.
3. Render useCounter (no useEffect) -> returns 1.
4. Render App (no useEffect) -> current counter 1.
5. Run useEffect in useCounter.
6. Run useEffect in App.
7. Cleanup useEffect in useCounter -> clean counter 1.
8. Cleanup useEffect in App -> clean counter 1.
9. Run useEffect in useCounter.
10. Run useEffect in App.
11. (At this point, counter is 1 and globalCounter is 2)

[ivstas]

@gianlucadifrancesco thanks for such a clean reproduction.
You see, the counter=0 doesn't get clean up, and my point was that it should be cleaned up instead of counter=1

[gianlucadifrancesco]

@ivstas Yep, it's actually "expected"!
It's discouraged to have a global variable like that in React: that's also one of the things that StrictMode helps to avoid, because you're basically mutating the state outside the scope of React, which doesn't expect that.

In fact, if you remove StrictMode, the rendering result will be different (which is a red flag): current counter 0.

I know it's kinda tricky actually, here's a more detailed explanation in the docs on why it should be avoided.

[ivstas]

@gianlucadifrancesco

It's discouraged to have a global variable like that in React

I know, but the goal was to show which render is being cleaned-up.
If the idea of <StrictMode> is to enforce developers to maintain cleanup cycle, why the first cleanup is being ommited?

In my original case I had "a disposable context" that was bound to component lifetime.
When I used this context in a child component later, it was already cleaned-up.

[gianlucadifrancesco]

The cleanup function is still called, but not immediately.
StrictMode unmounts and remounts the components, but doesn't call the cleanup function immediately after unmounting them. What it does is to call the cleanup after the component is mounted twice, and this is done on purpose in order to avoid impure things.

So, on load, instead of this: Mount -> useEffect -> ...
StrictMode does this: Mount -> Mount -> useEffect -> Cleanup -> useEffect -> ...

It basically adds another mount on the first time App is started.
This is done on purpose and, thanks to this, if there's something that React doesn't expect in the code, it's easier to spot it.

But feel free to provide a deeper example, more similar to the disposable context you're talking about! Maybe there's something different going on there.

[LoganDark]

It looks like the second render is what's being discarded, the first render's result is then being re-used.

So what's happening is probably:

• React renders app once
• React renders app again and then cleans it up
• React uses the results of the first render

So it's not that the wrong cleanup is being called, it's that a different render is being used than the one that you thought was being used.

Basically, strict mode is not the same as two full renders, it's more like each component's render function is called twice for each one actual render, if that makes any sense.

[ivstas]

It looks like the second render is what's being discarded, the first render's result is then being re-used

I would be happy if it was true, but unfortunately it's not. It uses the result of second (already cleaned up) render.

[LoganDark]

I would be happy if it was true, but unfortunately it's not. It uses the result of second (already cleaned up) render.

Oh, it's just running the effect twice.

This is a known property of strict mode, so nothing to worry about.

(Notably, it runs the effect twice without re-rendering App each time, as in it reuses the same callback you provided to useEffect.)

[LoganDark]

The only thing that was misleading is that you didn't log when the effect was called but destructor was not called. So you missed the critical detail where the effect is called again after the destructor.

Nothing to do with the counter IMHO.