关于 react18-batching-patterns
面向 React 18 类组件代码库的自动批处理参考技能,帮助诊断异步状态更新造成的隐性问题。它区分状态读取错误、重构场景和需要 flushSync 的情况,并强调谨慎使用同步刷新。
主要功能
- 01对比 React 17 与 18 的批处理行为
- 02诊断 await 后读取状态的问题
- 03区分重构与 flushSync 场景
- 04说明 flushSync 的适用条件
适用场景
- 01排查类组件异步状态错误
- 02检查 await 后的状态读取
- 03判断加载状态是否需要立即显示
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ github/ awesome-copilot --skill react18-batching-patterns安装后在 Claude Code 中输入/react18-batching-patterns确认已加载。
附带文件references/batching-categories.mdreferences/flushSync-guide.md
详细介绍
React 18 自动批处理模式
用于诊断和修复 React 18 中对 class 组件代码库最危险的静默破坏性变更的参考。
核心变更
| setState 的位置 | React 17 | React 18 |
|---|---|---|
| React 事件处理函数 | 批处理 | 批处理(相同) |
| setTimeout | 立即重新渲染 | 批处理 |
| Promise .then() / .catch() | 立即重新渲染 | 批处理 |
| async/await | 立即重新渲染 | 批处理 |
| 原生 addEventListener 回调 | 立即重新渲染 | 批处理 |
批处理意味着:该执行上下文中的所有 setState 调用会在末尾合并为一次重新渲染。不会发生中间渲染。
快速诊断
阅读每一个异步 class 方法。问:在 await 之后,是否有任何代码会读取 this.state 来做出决策?
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)
如需了解每一类的完整模式,请阅读:
references/batching-categories.md- 类别 A、B、C,包含完整的修改前后代码references/flushSync-guide.md- 何时使用 flushSync,何时不要使用,导入语法
flushSync 规则
谨慎使用 flushSync。 它会强制同步重新渲染,绕过 React 18 的并发调度器。过度使用会抵消 React 18 的性能优势。
仅在以下情况下使用 flushSync:
- 用户必须在异步操作开始前看到中间 UI 状态
- 加载指示器/加载状态必须在 fetch 开始前渲染
- 顺序 UI 步骤具有不同的可见状态(进度向导、多步骤流程)
在大多数情况下,修复方法是重构——调整代码结构,使其在 await 之后不再读取 this.state。请阅读 references/batching-categories.md,了解每一类的正确做法。
评论
支持 Markdown