Frontend Beauty
ESC

Type to search the knowledge base.

flushSync Rare Cases

flushSync forces React to flush updates synchronously: measuring DOM after setState, and why overuse hurts.

advanced3 min read
  • react
  • flushsync-rare

React 18 batches updates and may delay commits for performance. flushSync forces React to apply the provided updates synchronously and flush the DOM before continuing — an escape hatch, not a default tool.

Docs: flushSync.

When it is justified

You set state that mounts or reveals a node, then immediately need to measure or focus it in the same event handler:

import { flushSync } from 'react-dom';

function Expandable() {
  const [open, setOpen] = useState(false);
  const panelRef = useRef(null);

  function openAndScroll() {
    flushSync(() => {
      setOpen(true);
    });
    panelRef.current?.scrollIntoView({ behavior: 'smooth' });
  }

  return (
    <>
      <button type="button" onClick={openAndScroll}>Open</button>
      {open && <div ref={panelRef}>Details…</div>}
    </>
  );
}

Without flushSync, panelRef.current may still be null because the commit has not run yet.

Prefer alternatives first

Need Prefer
Focus after open useEffect / useLayoutEffect on open
Measure layout useLayoutEffect
Integrate janky third-party Narrow flushSync at the boundary
“Make batching go away” Do not — fix the data flow

Costs

flushSync forces layout work now, can defeat concurrent batching, and nested flushSync is especially expensive. Using it in hot paths (mousemove, scroll) is a footgun.

Interview out-loud

“flushSync forces React to commit updates synchronously so the next line can read the DOM. I use it rarely for measure/focus immediately after mounting UI, and I prefer layout effects when the work can wait until after commit in the effect phase.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides