A React sidebar measures its own width once with useLayoutEffect and stores it in state, but the sidebar is user-resizable and the stored width goes stale. How do you keep the measurement current, and what has to happen in the effect's cleanup?

## Why the one-shot measurement is wrong, not just incomplete `useLayoutEffect(() => { setWidth(el.offsetWidth); }, [])` answers the question "how wide was this element at the moment it first mounted". Everything else that changes an element's size leaves that answer untouched: the user dragging a splitter, a sibling in the same flex row growing, a web font finishing load and reflowing the text, content being added, the browser window zooming, a container query flipping a layout, an ancestor collapsing. The component keeps rendering against a number that stopped being true. The general fix is to stop treating size as a value you read and start treating it as a stream you subscribe to. ## ResizeObserver, and what it reports `ResizeObserver` is a browser API that notifies you when an observed element's box changes size, without you polling and without you forcing layout. You construct it with a callback, call `observe(node)` for each element you care about, and the callback receives an array of entries. Each entry carries the observed `target` and its measured geometry. `entry.contentRect` gives a rect for the content box; `entry.borderBoxSize` and `entry.contentBoxSize` are arrays of size objects with `inlineSize` and `blockSize` (writing-mode aware — for normal horizontal text, inline is width and block is height). Reading these is cheap because the browser measured them for you; you are not calling `getBoundingClientRect()` and forcing a layout recalculation. Two behaviours matter for React code: - Calling `observe()` delivers an initial observation with the element's current size. That is why the observer can replace your first manual measurement instead of supplementing it. - The callback is delivered by the browser at a point where you may safely read layout, and if your callback resizes the observed elements, the browser can report a resize-loop error rather than spinning forever. Treat that error as a signal that your callback writes something that feeds back into the size it measures. ## Wiring it into a component correctly Three things have to line up: the observer must be created where you have a node, torn down when you lose it, and it must not fight your own renders. ```jsx useEffect(() => { const node = ref.current; if (!node) return; const observer = new ResizeObserver(([entry]) => { setWidth(entry.contentRect.width); }); observer.observe(node); return () => observer.disconnect(); }, []); ``` The cleanup is not optional bookkeeping. Without `disconnect()`, the observer object stays registered with the browser, keeps a strong reference to a node that is no longer in the document, and keeps invoking a callback that calls `setState` on an unmounted component. If the effect re-runs for any reason you now have two live observers, both writing to the same state, and in development StrictMode deliberately mounts, unmounts and remounts your component so a missing cleanup shows up immediately as a doubled observer. Whether you can use `useEffect` or need `useLayoutEffect` depends on what you do with the number. If the size only feeds a later visual decision, a passive effect is fine and keeps the work off the critical path. If the first painted frame would visibly be wrong without it, measure in a layout effect. ## Guarding the state write A size-driven component is a feedback loop waiting to happen: state changes → render changes layout → element resizes → callback fires → state changes. Even when there is no true loop, writing a new object on every notification re-renders on every scroll-driven sub-pixel change. Compare before you write: ```jsx setSize((prev) => prev.width === next.width && prev.height === next.height ? prev : next ); ``` Returning the previous state object lets React bail out of the re-render entirely. ## Why a window resize listener is not the same thing `window.addEventListener('resize', ...)` fires when the viewport changes. It does not fire when a splitter is dragged, when a sibling grows, when text reflows after a font loads, when content is inserted, or when an ancestor's `display` changes. It also fires for elements whose size did not change, so you pay for measurements you did not need. The observer answers the question you actually asked: did *this element* change size. ## Attaching to the right node An effect with `[]` captures whatever node exists at first commit. If the observed element is conditionally rendered or swapped for a different element, the observer keeps pointing at a stale node. Wiring the observer through a callback ref instead — creating it when React hands you the node and disconnecting when it hands you `null` or runs the returned cleanup in React 19 — makes attachment follow the node's real lifetime rather than the component's. ## The same shape applies to IntersectionObserver Visibility works identically: construct an `IntersectionObserver` in an effect against the ref's node, read `entry.isIntersecting` in the callback, and `disconnect()` in the cleanup. It is the same subscribe-and-tear-down discipline applied to a different measurement.