AutoGineer
Generated banner for React18 Batching Patterns
Generated logo for React18 Batching Patterns

React18 Batching Patterns

GitHubOfficialFirst committed by SaravananRajaramanDistributed by GitHub

  • Skill
  • Guidelines
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

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 here prevents unnecessary flushSync overuse. Also use this skill when fixing test failures caused by intermediate state assertions that break after React 18 upgrade.
— the description by SaravananRajaraman

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

React 18 introduced automatic batching for async operations, which can break legacy class components that rely on immediate re-renders after setState calls. This skill provides a decision framework to categorize these regressions into three types: logic errors caused by reading stale state after await, independent state updates that can be refactored, and scenarios requiring synchronous rendering via flushSync. It emphasizes refactoring over the use of flushSync to maintain React's performance benefits.

What it does

  • Provides a diagnostic decision tree for React 18 batching issues.
  • Defines three categories of batching regressions (A, B, and C).
  • Offers refactoring patterns to replace stale state reads with local variables.
  • Explains the correct usage and import syntax for flushSync.
  • Identifies anti-patterns where flushSync is misused or unnecessary.
  • Helps resolve test failures caused by intermediate state assertions.

When to use it

  • When upgrading class components to React 18 and encountering state-related bugs.
  • When multiple setState calls in async methods, Promises, or timeouts behave unexpectedly.
  • Before implementing flushSync to ensure it is the appropriate solution.
  • When fixing test failures that occur after React 18 migration.

Advantages

  • Prevents unnecessary performance degradation caused by overusing flushSync.
  • Provides clear, actionable refactoring patterns for common bugs.
  • Reduces silent state-read bugs by promoting better async state management.
  • Helps maintain the performance benefits of React 18 concurrent rendering.

Usage examples

“How do I fix a bug where my class component reads this.state after an await and gets the old value?”
The skill guides you to Category A, advising you to remove the conditional state read and use local variables or restructure the logic to avoid relying on intermediate state.
“When is it appropriate to use flushSync in a React 18 class component?”
The skill explains that flushSync should only be used when the user must see an intermediate UI state, such as a loading spinner, before an async operation begins.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/github/react18-batching-patterns/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip react18-batching-patterns.zip -d .agents/skills

Documentation by SaravananRajaraman

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 setStateReact 17React 18
React event handlerBatchedBatched (same)
setTimeoutImmediate re-renderBatched
Promise .then() / .catch()Immediate re-renderBatched
async/awaitImmediate re-renderBatched
Native addEventListener callbackImmediate re-renderBatched

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.

Files

SKILL.md

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 setStateReact 17React 18
React event handlerBatchedBatched (same)
setTimeoutImmediate re-renderBatched
Promise .then() / .catch()Immediate re-renderBatched
async/awaitImmediate re-renderBatched
Native addEventListener callbackImmediate re-renderBatched

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.

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by
GitHub avatar of SaravananRajaramanSaravananRajaraman
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/react18-batching-patterns · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
SaravananRajaraman

AutoGineer is not affiliated with or endorsed by SaravananRajaraman or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download react18-batching-patterns.zip