react18-batching-patterns

React 18 Automatic Batching Patterns Reference for diagnosing and fixing the most dangerous silent breaking change in React 18 for class-component codebases. The Core Change Location of setState React 17 React 18 React event handler Batched Batched (same) setTimeout Immediate re-render Batched Promise .then() / .catch() Immediate re-render Batched async/await Immediate re-render Batched Native addEventListener callback Immediate re-render Batched Batched means: all setState calls within that execution context flush together in a single re-render at the end. No intermediate renders occur. Quick Diagnosis Read every async class method. Ask: does any code after an await read this.state to make a decision? Code reads this.state after await? YES → Category A (silent state-read bug) NO, but intermediate render must be visible to user? YES → Category C (flushSync needed) NO → Category B (refactor, no flushSync) For the full pattern for each category, read: references/batching-categories.md - Category A, B, C with full before/after code references/flushSync-guide.md - when to use flushSync, when NOT to, import syntax The flushSync Rule Use flushSync sparingly. It forces a synchronous re-render, bypassing React 18's concurrent scheduler. Overusing it negates the performance benefits of React 18. Only use flushSync when: The user must see an intermediate UI state before an async operation begins A spinner/loading state must render before a fetch starts Sequential UI steps have distinct visible states (progress wizard, multi-step flow) In most cases, the fix is a refactor - restructuring the code to not read this.state after await . Read references/batching-categories.md for the correct approach per category.