When you call observe(el) on a ResizeObserver, when does the callback first run, and what do unobserve() and disconnect() each do when the code that created the observer is torn down?

## observe() starts a subscription, not a one-shot read `ResizeObserver` has exactly three methods: `observe(target, options)`, `unobserve(target)` and `disconnect()`. Constructing the observer does nothing on its own; the first `observe()` call is what puts it to work. ```javascript const ro = new ResizeObserver((entries) => { /* ... */ }); ro.observe(el); ``` From that moment the element is in the observer's list of observation targets, and stays there until you remove it. ## The initial notification The behaviour that surprises people: **the callback fires once shortly after `observe()`, before anything has resized.** When observation begins on an element that is being rendered, that element counts as having an active observation, so the next time the browser runs its rendering update it delivers an entry with the element's current size. This is deliberate and helpful — you get the starting measurement without a separate `getBoundingClientRect()` call, and code that reacts to size does not have to special-case "the first time". But two consequences follow. First, the callback runs asynchronously, on the next frame, not synchronously inside `observe()` — so you cannot read the size on the very next line. Second, any logic of the shape "the user just resized me, animate the change" will run spuriously on mount unless you guard it. An element that is not rendered — `display: none`, or not in the document — generates no box, so there is nothing meaningful to report; write callbacks that tolerate zero sizes rather than treating every delivery as a real layout. ## What arrives afterwards After the initial delivery, entries arrive only for targets whose observed box actually changed. Delivery is batched: one callback invocation per observer per frame, carrying an array of the changed entries. Ten observed elements that all change in the same frame produce one callback with ten entries, which is why looping over `entries` — rather than assuming `entries[0]` is the one you care about — matters as soon as an observer watches more than one target. ## Re-observing the same target Calling `observe()` twice on the same element does not create two observations. The existing observation for that target is replaced, which is how you change the `box` option for an already-observed element. It also means an accidental repeat in a re-run effect is not a leak of observations — but it does trigger a fresh initial notification, which can look like a spurious resize. ## unobserve versus disconnect - `ro.unobserve(el)` removes one target. Everything else the observer watches continues. Use it when one item disappears from a list that a shared observer is watching. - `ro.disconnect()` removes all targets at once. The observer object survives and can be reused — calling `observe()` on it later starts fresh, including a new initial notification. `disconnect()` is not a destructor; it is "stop watching everything". Both are idempotent in practice: unobserving something you are not observing does nothing. ## Why teardown is your job The reliable rule is: whatever created the observer owns disconnecting it, in the same scope, on every exit path. Do not reason about whether the browser can collect a detached node while an observer references it — that is not a contract you can build on. What you *can* observe is the failure mode: an observer that is still observing still runs your callback, and that callback typically closes over things that are gone — a removed DOM node it wants to write to, a store that has been reset, a component instance that no longer exists. In a single-page app that navigates many times, forgotten observers accumulate one per visit, each doing a little work every frame in which its target changes. The pattern that avoids the mistake is to make the subscription return its own cleanup, so no caller has to remember two symmetrical calls: ```javascript function watchSize(el, onSize) { const ro = new ResizeObserver(([entry]) => onSize(entry.contentBoxSize[0].inlineSize)); ro.observe(el); return () => ro.disconnect(); } ``` When an observer is private to one element, `disconnect()` and `unobserve(el)` are equivalent, and `disconnect()` is the safer habit because it cannot be left holding a target you forgot about. When the observer is shared across many elements, `unobserve()` per element is the correct call and `disconnect()` would silently break every other subscriber.