A design system has thirty components, and each one constructs its own ResizeObserver when it mounts. As the lead, how would you decide between per-instance observers and a single shared observer with an element-to-handler registry, and what does each option cost?

## What is actually being chosen The question is framed as a performance one, and it usually is not. Both designs observe the same elements and require the browser to compute the same layout and generate the same observations. What differs is the number of `ResizeObserver` objects, the number of times your callback code is entered per frame, and — most importantly — where the rules about size-driven behaviour live. ## The per-instance shape Each component constructs an observer in its setup path and disconnects it in teardown. Strengths: ownership is obvious and local, teardown is a single `disconnect()` on an observer with exactly one target, a throwing callback affects only that component, and the `box` option and rounding policy are chosen where the component's semantics are known. There is nothing global to initialise, which also keeps server-side rendering and module-import order uninteresting. Weaknesses: thirty components mean thirty observer objects and, in a frame where all thirty resize, thirty separate callback invocations. Each is another entry point where someone can write a feedback loop or forget the zero-size guard. There is no place to fix a systemic mistake once. ## The shared shape One observer, one `Map` from element to handler, and one `subscribe` function: ```javascript const handlers = new Map(); let ro = null; export function observeSize(el, handler) { ro ??= new ResizeObserver((entries) => { for (const entry of entries) { try { handlers.get(entry.target)?.(entry); } catch (err) { console.error(err); } } }); handlers.set(el, handler); ro.observe(el); return () => { handlers.delete(el); ro.unobserve(el); }; } ``` Note that `box` is an argument to `observe()`, not to the constructor, so a shared observer can still watch one element by border box and another by content box — sharing does not force one convention. Strengths: one callback invocation per frame carrying every changed entry; one place that rounds sizes and refuses to write anything that could resize an observed element; one place to catch a handler's exception so it cannot skip the remaining entries in the batch; and an API that hands back its own unsubscribe, which is the single most effective defence against leaked observations. Weaknesses: it is a singleton. Its lifetime spans route changes and hot reloads. The `Map` holds strong references to elements and handlers, so an entry never deleted keeps a detached subtree and its closure alive — a leak the per-instance design cannot have, because there the observer dies with the component. Dispatch cost is trivial, but the shared callback is a shared failure point, and a subtle bug in it is a bug in thirty components at once. ## Deciding Measure before centralising. If a profile does not show observer overhead, the performance argument is not available and you are choosing on architecture alone. I default to per-instance for ordinary components, because local ownership is worth more than a handful of objects, and I centralise when one of three things is true. First, **cardinality**: a virtualised list or grid that observes hundreds of cells, where per-instance construction and teardown churn is real. Second, **policy**: there is a rule every consumer must follow — snap to a breakpoint, never write a size from the callback, always tolerate zero sizes — and I want it enforced in one implementation rather than reviewed thirty times. Third, **API shape**: I want the only public way to react to size to be a subscription that cannot be left dangling. When I do centralise, I want the registry keyed by element with deletion on unsubscribe as an invariant, a test that asserts the map empties after teardown, and per-entry error isolation so one bad handler cannot silence the batch. ## The question behind the question Thirty components each observing their own size is itself a signal worth examining. Some of that work is genuinely imperative — telling a virtualised list how many rows fit, driving a measurement-dependent library. Some of it is layout logic that has drifted into JavaScript. As a lead the more valuable intervention is often to shrink the number of subscriptions rather than to make subscribing cheaper: fewer elements whose behaviour depends on a measured pixel value means fewer feedback loops, fewer teardown paths, and less to centralise in the first place.