Update queueing-a-series-of-state-updates.md #7731
Conversation
The thin line between setter logic and batching lies in their distinct roles: setters initiate state updates, while batching determines how React schedules and groups these updates for efficient re-renders.
| @@ -63,6 +63,12 @@ This might remind you of a waiter taking an order at the restaurant. A waiter do | |||
|
|
|||
| This lets you update multiple state variables--even from multiple components--without triggering too many [re-renders.](/learn/render-and-commit#re-renders-when-state-updates) But this also means that the UI won't be updated until _after_ your event handler, and any code in it, completes. This behavior, also known as **batching,** makes your React app run much faster. It also avoids dealing with confusing "half-finished" renders where only some of the variables have been updated. | |||
|
|
|||
| <Note> | |||
|
|
|||
| Batching refers to how React groups multiple state updates into a single re-render, and does not affect the behavior of individual state setters. | |||
There was a problem hiding this comment.
Can you explain what you mean by this? On first read it doesn't sound accurate, but maybe I'm reading it wrong and can suggest alternatives.
There was a problem hiding this comment.
One of those, maybe ?:
"When you call a state setter in React, it schedules a re-render. Batching is the mechanism that groups those scheduled re-renders together so React doesn't re-render after every single update."
"Batching is React’s way of batching state updates into a single re-render, without affecting how expressions like setNumber(number + 1) calculate their value."
"Batching does not influence how state setters compute their values; it only determines when updates are processed and rendered."
The point is to emphasize that batching only affects when React re-renders, not how the setters update the state. That’s the subtle but essential line between setter logic and batching to prevent future confusion about this topic
There was a problem hiding this comment.
I think I'm still confused about what's confusing. Can you help me understand why the distinction makes this page clearer? How do you know that this:
setNumber(number + 1);
setNumber(number + 1);
setNumber(number + 1);
Does not result in 3?
Maybe you'd say "well number refers to the old number in the closure" which is correct in React, but isn't what new developers might expect, especially if they come from other libraries where number would be updated between calls.
Closures are also complicated to understand, so this page explains it in terms of "queuing the the updates", and if you're queueing them then they can't be updated in between the calls, which explains why it's not three. So batching, while not the strict cause of the behavior, is a nice way to think about the behavior while also talking about the performance behavior.
There was a problem hiding this comment.
I completely agree with your point. However, what I’m trying to highlight is that for a developer who is new to React—regardless of their seniority—it’s not straightforward to clearly understand what “batching” actually means. I’ve observed this confusion during interviews, and even experienced developers I know often mix up the concepts when discussing examples.
To illustrate, you mentioned in your previous message: “So batching, while not the strict cause of the behavior…”—and that’s precisely my point. Where in the official documentation is this explained clearly, with examples or detailed clarification? Without that, it’s difficult for someone new to React to grasp the concept with confidence.
The thin line between setter logic and batching lies in their distinct roles: setters initiate state updates, while batching determines how React schedules and groups these updates for efficient re-renders.
The pull request was initiated as a result of this Reddit thread:
https://www.reddit.com/r/reactjs/comments/1jtnbef/comment/mm0v20w/?context=3