After migrating a React class to a function component, a popover's measuring code that used to run in this.setState({ open: true }, () => this.measure()) now measures the old layout. Why, and how do you restore the ordering?

## What the class callback guaranteed ```jsx this.setState({ open: true }, () => { this.setState({ height: this.node.getBoundingClientRect().height }); }); ``` The second argument to `setState` ran **after** React processed the update, re-rendered and committed to the DOM. That gave the callback two useful properties at once: the state it just set was applied, and the DOM reflected it. Measuring code, focus management and "scroll to the thing that just appeared" all leaned on it. ## Why the literal port breaks ```jsx function Popover() { const [open, setOpen] = useState(false); function handleClick() { setOpen(true); measure(); // reads the DOM as it is right now — closed } } ``` Two things go wrong. First, `open` is a `const` for the duration of this render; calling the setter schedules an update, it does not reassign the variable, so anything after it in the handler still sees the old value. Second, React does not re-render synchronously inside the handler — updates are batched and processed afterwards, so the DOM has not changed yet when `measure()` runs. The measurement is of the previous layout, and because it is *usually* only one frame stale, the bug tends to show up as an occasional misplacement rather than a hard failure. ## The replacement The class callback answered the question "what should happen once this update is on screen?" In a function component that question is answered by an effect that depends on the value: ```jsx useLayoutEffect(() => { if (!open) return; setHeight(ref.current.getBoundingClientRect().height); }, [open]); ``` Use `useLayoutEffect` when the result changes what the user sees this frame — measuring, positioning, focusing, restoring scroll. It runs after the DOM mutation and before the browser paints, which is precisely where `componentDidUpdate` and the `setState` callback ran, so nothing flickers. Use plain `useEffect` when the work is logging, analytics or a request, so it does not block the paint. This is also more robust than the callback ever was: the effect fires whenever `open` becomes true, regardless of which code path set it. The class version only ran for the one call site that remembered to pass a callback. ## The other thing the callback was used for A large share of class-era `setState` callbacks were not about the DOM at all — they were about reading the value you just set, because `this.state` was not updated synchronously: ```jsx this.setState({ count: this.state.count + 1 }, () => console.log(this.state.count)); ``` That use has a different answer. The updater form gives you the pending value directly and composes correctly when several updates queue up in one batch: ```jsx setCount((c) => c + 1); ``` Conflating the two is the common mistake in review: an effect appears where an updater function was needed, adding a render for no reason. ## When synchronous really is required Occasionally non-React code has to observe the updated DOM before the handler returns — a third-party widget that must be told a new size immediately, or a `print()` that has to see the expanded content. `flushSync` from `react-dom` forces React to render and commit that update synchronously, so the DOM is up to date when the call returns. It defeats batching and costs a synchronous render, so it is an escape hatch justified by an interop requirement, not a convenience for ordering your own code. ## How to present it Name the mechanism first — the setter has no callback and state is a snapshot for the current render, so nothing after the setter sees the new value or the new DOM. Then give the replacement and, importantly, distinguish the two uses of the old callback: "after it is committed" is an effect keyed on the value, while "using the value I just set" is the updater form.