Two related questions: how re-renders work, and what stays in memory between them.

How re-renders happen

1. State setter is called → React enqueues an update on the owning fiber.
2. React schedules a render (sync or via concurrent scheduler).
3. The component function is called again — top to bottom.
4. Hooks read their stored values from the fiber by call order.
5. JSX is returned → new VDOM tree.
6. React diffs against previous tree.
7. Minimal DOM mutations are committed.
8. Effects run after paint (useEffect) or before (useLayoutEffect).

What persists across renders

Per fiber (React's internal node for each component instance):

• useState values — stored on the hook slot.
• useRef.current — mutable, survives renders.
• useMemo / useCallback caches — until deps change.
• Effect cleanup functions — invoked before the next setup.
• DOM node references — attached via ref.
• Context subscriptions — fibers register interest.

What's collected

• Previous VDOM — plain objects, eligible for GC once the new tree commits.
• Discarded DOM nodes — removed from parent, GC'd if not referenced elsewhere.
• Unmounted fibers — released after cleanup runs.

Memory leak sources

1. Uncleaned subscriptions / timers.

useEffect(() => {
  const id = setInterval(tick, 1000);
  return () => clearInterval(id); // critical
}, []);

2. Event listeners on window/document.

useEffect(() => {
  const onResize = () => setW(window.innerWidth);
  window.addEventListener('resize', onResize);
  return () => window.removeEventListener('resize', onResize);
}, []);

3. Detached DOM held by a ref.

A ref pointing to a DOM node that's been unmounted but the ref is held by a closure or external structure prevents GC.

4. setState after unmount (in-flight async).

useEffect(() => {
  let alive = true;
  fetch(url).then(r => r.json()).then(d => {
    if (alive) setData(d);
  });
  return () => { alive = false; };
}, [url]);

Better: AbortController.

useEffect(() => {
  const ctrl = new AbortController();
  fetch(url, { signal: ctrl.signal }).then(...);
  return () => ctrl.abort();
}, [url]);

5. Closures capturing big state.

Long-lived handlers that capture large props/state can keep them alive after the component unmounts.

StrictMode helps surface these

In dev, React 18 mounts → unmounts → mounts every component once. Cleanup that doesn't reverse setup fully will fail loudly.

Profiling

• Chrome DevTools → Memory → heap snapshot → look for 'Detached HTMLElement' or large component instance counts.
• Take a snapshot, navigate away, force GC, take another. Same instances? Leak.
• React DevTools Profiler shows commit duration but not memory.

Performance vs memory tradeoffs

• useMemo / useCallback caches add memory to save CPU.
• Memoized leaf components retain their old subtree until next render.
• React's fiber tree itself has overhead — typically ~1 KB per component instance.

For huge component trees, memory can be the bottleneck before CPU.