Detached Nodes and What Keeps Them Alive

• Break any single edge and the whole subtree is collectable. The cheapest edge to break is almost always the first one — remove the listener.
• The data node is why leaks are bigger than they look: a closure retains its entire scope, not the variables it happens to reference.
• The same shape applies with a timer, an observer, an event bus, a module-level Map or a framework store in place of the listener list.

1. 1
   Reach a stable state

   Load the app and navigate to the view under suspicion once, so lazy chunks, caches and pools are already warm.

   fails by Snapshotting on first load, where everything is legitimately new and nothing is comparable.

2. 2
   Force a collection, snapshot 1

   Establishes the baseline the other two are compared against.

   fails by Skipping the forced collection, which makes every later comparison include ordinary heap growth.

3. 3
   Exercise the suspect flow repeatedly

   Enter and leave the view five or ten times. Repetition turns a small leak into an unmistakable slope and averages out one-off allocation.

   fails by Doing it once — a single iteration cannot distinguish a leak from a cache filling up.

4. 4
   Return to the baseline state, force a collection, snapshot 2

   Everything allocated by the flow should now be unreachable. What remains is what leaked.

   fails by Returning to a different state, so the diff includes whatever the new state legitimately allocated.

5. 5
   Diff, filter to Detached, read the retainers

   Names the retaining path: the object, the closure and the source location holding each detached node.

   fails by Reading object counts instead of retaining paths. The count tells you there is a leak; only the path tells you where.

6. 6
   Break the edge, then repeat the whole procedure

   Confirms the fix and catches the common case of a second retaining path behind the first.

   fails by Declaring victory on one iteration — leaks routinely come in pairs, because the same missing teardown covered several subscriptions.

The repetition in steps three and six is the method. A single before-and-after pair is not evidence about memory.

1function mountPanel(root: HTMLElement, url: string) {
2  // One controller for everything this component subscribes to.
3  const ac = new AbortController()
4  const { signal } = ac
5 
6  // Listeners on targets that outlive the component: the leak-prone case.
7  window.addEventListener('resize', onResize, { signal })
8  document.addEventListener('visibilitychange', onVisible, { signal })
9 
10  // Delegated: one listener on a stable container, unaffected by row churn.
11  root.addEventListener('click', onRowClick, { signal })
12 
13  // The same signal aborts in-flight work, so a late response cannot
14  // re-attach anything to a subtree that is being discarded.
15  fetch(url, { signal })
16    .then((r) => r.json())
17    .then(render)
18    .catch((e) => { if (e.name !== 'AbortError') report(e) })
19 
20  // Observers are NOT covered by the signal — they need explicit disconnect.
21  const ro = new ResizeObserver(onResize)
22  ro.observe(root)
23 
24  // Per-node metadata without retaining the node.
25  const measured = new WeakMap<Element, DOMRect>()
26 
27  return function unmount() {
28    ac.abort()        // every listener above, plus the fetch, in one call
29    ro.disconnect()   // the one thing that has to be said separately
30    root.replaceChildren()
31    // `measured` needs no cleanup: its keys are weak.
32  }
33}

The value of the pattern is that teardown is auditable. A reviewer checks that unmount is called and that nothing subscribed without the signal, rather than checking that every addEventListener has a matching removeEventListener somewhere.