Provides exact patterns for diagnosing and fixing automatic batching regressions in React 18 class components. Use this skill whenever a class component has multiple setState calls in an async method, inside setTimeout, inside a Promise .then() or .catch(), or in a native event handler. Use it befor

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? 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.

react18-batching-patterns