协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
react18-batching-patterns【开发与工程】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 before writing any flushSync call - the decision tree her…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Reference for diagnosing and fixing the most dangerous silent breaking change in React 18 for class-component codebases.
| 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.
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 codereferences/flushSync-guide.md - when to use flushSync, when NOT to, import syntaxUse 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:
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.