Automatic batching for fewer renders in React 18

[gaearon]

Overview

React 18 adds out-of-the-box performance improvements by doing more batching by default, removing the need to manually batch updates in application or library code. This post will explain what batching is, how it previously worked, and what has changed.

Note: this is an in-depth feature that we don’t expect most users to need to think about. However, it may be relevant to educators and library developers.

What is batching?

Batching is when React groups multiple state updates into a single re-render for better performance.

For example, if you have two state updates inside of the same click event, React has always batched these into one re-render. If you run the following code, you’ll see that every time you click, React only performs a single render although you set the state twice:

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    setCount(c => c + 1); // Does not re-render yet
    setFlag(f => !f); // Does not re-render yet
    // React will only re-render once at the end (that's batching!)
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

• ✅ Demo: React 17 batches inside event handlers. (Notice one render per click in the console.)

This is great for performance because it avoids unnecessary re-renders. It also prevents your component from rendering “half-finished” states where only one state variable was updated, which may cause bugs. This might remind you of how a restaurant waiter doesn’t run to the kitchen when you choose the first dish, but waits for you to finish your order.

However, React wasn’t consistent about when it batches updates. For example, if you need to fetch data, and then update the state in the handleClick above, then React would not batch the updates, and perform two independent updates.

This is because React used to only batch updates during a browser event (like click), but here we’re updating the state after the event has already been handled (in fetch callback):

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    fetchSomething().then(() => {
      // React 17 and earlier does NOT batch these because
      // they run *after* the event in a callback, not *during* it
      setCount(c => c + 1); // Causes a re-render
      setFlag(f => !f); // Causes a re-render
    });
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

• 🟡 Demo: React 17 does NOT batch outside event handlers. (Notice two renders per click in the console.)

Until React 18, we only batched updates during the React event handlers. Updates inside of promises, setTimeout, native event handlers, or any other event were not batched in React by default.

What is automatic batching?

Starting in React 18 with createRoot, all updates will be automatically batched, no matter where they originate from.

This means that updates inside of timeouts, promises, native event handlers or any other event will batch the same way as updates inside of React events. We expect this to result in less work rendering, and therefore better performance in your applications:

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    fetchSomething().then(() => {
      // React 18 and later DOES batch these:
      setCount(c => c + 1);
      setFlag(f => !f);
      // React will only re-render once at the end (that's batching!)
    });
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

• ✅ Demo: React 18 with createRoot batches even outside event handlers! (Notice one render per click in the console!)
• 🟡 Demo: React 18 with legacy render keeps the old behavior (Notice two renders per click in the console.)

Note: It is expected that you will upgrade to createRoot as part of adopting React 18. The old behavior with render only exists to make it easier to do production experiments with both versions.

React will batch updates automatically, no matter where the updates happen, so this:

function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}

behaves the same as this:

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}, 1000);

behaves the same as this:

fetch(/*...*/).then(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
})

behaves the same as this:

elm.addEventListener('click', () => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
});

Note: React only batches updates when it’s generally safe to do. For example, React ensures that for each user-initiated event like a click or a keypress, the DOM is fully updated before the next event. This ensures, for example, that a form that disables on submit can’t be submitted twice.

What if I don’t want to batch?

Usually, batching is safe, but some code may depend on reading something from the DOM immediately after a state change. For those use cases, you can use ReactDOM.flushSync() to opt out of batching:

import { flushSync } from 'react-dom'; // Note: react-dom, not react

function handleClick() {
  flushSync(() => {
    setCounter(c => c + 1);
  });
  // React has updated the DOM by now
  flushSync(() => {
    setFlag(f => !f);
  });
  // React has updated the DOM by now
}

We don't expect this to be common.

Does this break anything for Hooks?

If you’re using Hooks, we expect automatic batching to "just work" in the vast majority of cases. (Tell us if it doesn't!)

Does this break anything for Classes?

Keep in mind that updates during React event handlers have always been batched, so for those updates there are no changes.

There is an edge cases in class components where this can be an issue.

Class components had an implementation quirk where it was possible to synchronously read state updates inside of events. This means you would be able to read this.state between the calls to setState:

handleClick = () => {
  setTimeout(() => {
    this.setState(({ count }) => ({ count: count + 1 }));

    // { count: 1, flag: false }
    console.log(this.state);

    this.setState(({ flag }) => ({ flag: !flag }));
  });
};

In React 18, this is no longer the case. Since all of the updates even in setTimeout are batched, React doesn’t render the result of the first setState synchronously—the render occurs during the next browser tick. So the render hasn’t happened yet:

handleClick = () => {
  setTimeout(() => {
    this.setState(({ count }) => ({ count: count + 1 }));

    // { count: 0, flag: false }
    console.log(this.state);

    this.setState(({ flag }) => ({ flag: !flag }));
  });
};

See sandbox.

If this is a blocker to upgrading to React 18, you can use ReactDOM.flushSync to force an update, but we recommend using this sparingly:

handleClick = () => {
  setTimeout(() => {
    ReactDOM.flushSync(() => {
      this.setState(({ count }) => ({ count: count + 1 }));
    });

    // { count: 1, flag: false }
    console.log(this.state);

    this.setState(({ flag }) => ({ flag: !flag }));
  });
};

See sandbox.

This issue doesn't affect function components with Hooks because setting state doesn't update the existing variable from useState:

function handleClick() {
  setTimeout(() => {
    console.log(count); // 0
    setCount(c => c + 1);
    setCount(c => c + 1);
    setCount(c => c + 1);
    console.log(count); // 0
  }, 1000)

While this behavior may have been surprising when you adopted Hooks, it paved the way for automated batching.

What about unstable_batchedUpdates?

Some React libraries use this undocumented API to force setState outside of event handlers to be batched:

import { unstable_batchedUpdates } from 'react-dom';

unstable_batchedUpdates(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
});

This API still exists in 18, but it isn't necessary anymore because batching happens automatically. We are not removing it in 18, although it might get removed in a future major version after popular libraries no longer depend on its existence.

[chantastic]

This is a fantastically clear piece of writing, @gaearon. I love the sandbox examples. I was — admittedly — unaware of the different behaviors but feel like I could explain it after this description.

This post has a secondary effect of clarifying render vs createRoot as an "as part of adopting React 18". This is a very nice "upgrade carrot" ⬆️🥕. And you've given folks something to look for to identify success. Wins all 'round.

[eps1lon]

TL;DR: Is this change intended?

-act(() => {
+await act(async () => {
  button.click()
})

// assert on effects scheduled by click()

In React 17 and below act(callback) ensured that every update and effect scheduled by callback() was actually flushed before returning. We had both a synchronous variant (act(() => {})) and an asynchronous variant (await act(async () => {})). Choosing which one to use was a matter of whether the callback returned a promise or not i.e. what "color" the callback has.

Now that passive effects from discrete events schedule a sync callback as opposed to a normal passive effect, they're no longer flushed in sync act. To put it more bluntly: act() doesn't seem to do anything here. We could just as well

button.click();
+await null;

// assert on effects scheduled by click()

I did some digging and I returned to the original behavior with

diff --git a/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js b/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js
index 91ce4c9c5f..59c7b10a77 100644
--- a/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js
+++ b/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js
@@ -193,8 +193,8 @@ export function act(callback: () => Thenable<mixed>): Thenable<void> {
         (isSchedulerMocked === false || previousIsSomeRendererActing === false)
       ) {
         // we're about to exit the act() scope,
-        // now's the time to flush effects
-        flushWork();
+        // now's the time to flush effects and sync callbacks
+        ReactDOM.flushSync(flushWork);
       }
       onDone();
     } catch (err) {

though it does feel heavy handed (I just want to flushSyncCallbacks technically).

full patch with updated tests

diff --git a/packages/react-dom/src/__tests__/ReactTestUtilsAct-test.js b/packages/react-dom/src/__tests__/ReactTestUtilsAct-test.js
index d2ea73e098..13d4c49ee8 100644
--- a/packages/react-dom/src/__tests__/ReactTestUtilsAct-test.js
+++ b/packages/react-dom/src/__tests__/ReactTestUtilsAct-test.js
@@ -150,7 +150,7 @@ function runActTests(label, render, unmount, rerender) {
         expect(Scheduler).toHaveYielded([100]);
       });
 
-      it('flushes effects on every call', async () => {
+      it('flushes effects on every call', () => {
         function App() {
           const [ctr, setCtr] = React.useState(0);
           React.useEffect(() => {
@@ -172,16 +172,16 @@ function runActTests(label, render, unmount, rerender) {
           button.dispatchEvent(new MouseEvent('click', {bubbles: true}));
         }
 
-        await act(async () => {
+        act(() => {
           click();
           click();
           click();
         });
         // it consolidates the 3 updates, then fires the effect
         expect(Scheduler).toHaveYielded([3]);
-        await act(async () => click());
+        act(() => click());
         expect(Scheduler).toHaveYielded([4]);
-        await act(async () => click());
+        act(() => click());
         expect(Scheduler).toHaveYielded([5]);
         expect(button.innerHTML).toBe('5');
       });
diff --git a/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js b/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js
index 91ce4c9c5f..59c7b10a77 100644
--- a/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js
+++ b/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js
@@ -193,8 +193,8 @@ export function act(callback: () => Thenable<mixed>): Thenable<void> {
         (isSchedulerMocked === false || previousIsSomeRendererActing === false)
       ) {
         // we're about to exit the act() scope,
-        // now's the time to flush effects
-        flushWork();
+        // now's the time to flush effects and sync callbacks
+        ReactDOM.flushSync(flushWork);
       }
       onDone();
     } catch (err) {

I'm dreadding the confusion and churn this would add at which point it would be more reasonable to just tell people to always use await act(async () => {}). Otherwise we'd have to teach people when to flush the microtask queue vs when to use act. It's not so much about adding await to act since that's code-moddable but rather about collecting all the abstractions using act (e.g. fireEvent from @testing-library/react) and adding await to them as well.

At the same time you also added a unstable_concurrentAct to internal tests which does hint at just supporting await act(async () => {}).

[acdlite]

We should start a separate thread on act at some point. There's a lot of planned work that needs to be done before release. What's implemented today is far from how we want it to work in the future.

Quick summary: the current implementation of act is more convoluted than it should be because we originally though we needed to support act in production mode. But we also didn't want to add act logic to the production React DOM bundle. So we had to implement act using clever user space tricks that don't work exactly as we'd like.

Instead, we decided that act doesn't need to exist in production mode. Production mode is only used for testing in e2e environments, where act isn't useful. (In an e2e environment, you perform an interaction and wait for the DOM to update; no special framework integration required.) act is really designed for integration and unit tests, which in practice everyone runs in development only.

Because act will only exist in development mode, we can add additional logic to the development build of React DOM. What it will do is post React tasks on a special React queue, instead of posting them to the browser like in a real app. Then act can flush that queue directly — and synchronously — without any clever hacks.

The upshot is that the sync version of act will work as you describe. No need for await null to flush promise microtasks because we won't have scheduled a microtask at all. Though it's still useful for cases where you want to simulate an async event handler.

[acdlite]

Created a separate thread here: #23

[ad1992]

Awesome post @gaearon, the explanation with examples is super helpful. This is gonna be a big performance boost 🔥 .

This also means that with react 18 createRoot, we don't need to use ReactDOM.unstable_batchedUpdates anymore as the batching will be automatically done right?

Some suggestions

Does this break anything for Classes?

We might want to mention here that it's only for cases where automatic batching was not happening earlier just to remind the user?

This issue doesn't affect function components with Hooks because they always see a "snapshot" of state from a particular render. With Hooks, setting state does not update the local state variable, even if rendering itself happened synchronously

can we add a snippet here just to make it more clear?

function handleClick() {
    console.log("=== click ===");
    fetchSomething().then(() => {
      // React 18 WITHOUT createRoot does not batches these:
      setCount((c) => c + 1); // Causes a re-render
      // count = 0, flag false
      console.log(count, flag);
      setFlag((f) => !f); // Causes a re-render
      // count = 0, flag false
      console.log(count, flag);
    });
  }

"they always see a "snapshot" of state from a particular render"
As I understand, the local variable doesn't get updated when setting state(even if synchronous/without batching) hence it's not reflected in hooks.
But here it says "it sees from the snapshot from a particular render" (which is happening synchronously), which means theoretically snapshot would have gotten updated and should be able to see it but that's not what happens, I might be missing something silly here so could you please elaborate?

Also to confirm thoughsetState is async but for the cases where batching wasn't happening earlier, it means setState was getting synchronously as a result the value was retrievable after setting state in class components?

[Andarist]

But here it says "it sees from the snapshot from a particular render" (which is happening synchronously), which means theoretically snapshot would have gotten updated and should be able to see it but that's not what happens

The snapshot cannot be updated because even if a new render happens synchronously then that render will create a new closure (by calling the component’s function again). The snapshot is the closure state and if you call a function that has access to a particular closure/snapshot then it will only ever have access to that specific closure/snapshot - it can’t easily access closures of any renders that happened because of it.

With classes the situation is different because the snapshot was put on the this which was available for all renders/methods/etc of any given component’s instance - so updated state could “leak” between renders~

[ad1992]

Thanks for the explanation @Andarist 💯

Suggestion: Though this is an implementation detail, can we add this in the post as well or maybe separate QnA which we can link here as well so it helps interested users to understand the reasoning behind this behavior?

[gaearon]

This also means that with react 18 createRoot, we don't need to use ReactDOM.unstable_batchedUpdates anymore as the batching will be automatically done right?

Yes.

We might want to mention here that it's only for cases where automatic batching was not happening earlier just to remind the user?

Added.

As I understand, the local variable doesn't get updated when setting state(even if synchronous/without batching) hence it's not reflected in hooks.

Yes.

But here it says "it sees from the snapshot from a particular render" (which is happening synchronously), which means theoretically snapshot would have gotten updated and should be able to see it but that's not what happens, I might be missing something silly here so could you please elaborate?

Sorry, I may have made it sound more complex than it is. All I meant is that the state you get from useState during a particular render will not change. Event handler "captures" values from that render, so it doesn't matter how many times you set the state -- that render's event handler will forever "see" the values from that render. That's what I meant by a snapshot. I reworded that part.

Also to confirm though setState is async but for the cases where batching wasn't happening earlier, it means setState was getting synchronously as a result the value was retrievable after setting state in class components?

Previously, in class components, in places where batching was not happening, you could read the next state from this.state. This is because React mutated this.state to point to the updated state in the middle of your function. With Hooks, this can't happen because there's nothing for React to mutate — there is no this. This is why this doesn't happen for Hooks.

[ad1992]

Thanks for making the edits and the answers @gaearon 👍🏻 , can we also add a note to convey to the users that ReactDOM.unstable_batchedUpdates will be still available but should no longer be needed?

Should a console warning be shown if ReactDOM.unstable_batchedUpdates used?

[gaearon]

Added a note at the end. We might eventually warn for it but for now it seems premature since many libraries use it and there's no harm in keeping it for now.

[markerikson]

Related question: will unstable_batchedUpdates still exist in React 18 for compat purposes, even if it's a noop?

[gaearon]

Yes.

[markerikson]

Follow-up thought on this:

If React 18 does batch by default, and React-Redux v8 has a minimum dependency on React 18, then we could just remove our own uses of unstable_batchedUpdates.

Now, currently we import that from either react-dom or react-native depending on the build environment. Any idea what the plans are for including React 18 with React Native? I don't know how those two get versioned together.

[gaearon]

I don’t think there’s a benefit to removing it. Doesn’t hurt to have it! Hard to say when 18 lands in RN.

[rickhanlonii]

What we can say is that React 18 won't land in React Native until after React 18 stable is released. Just upgrading the version will probably happen in the first React Native release after React 18 stable, but it's unclear whether React Native will be using the legacy root, the new root, or with an option to switch between them. Still TBD. cc @sammy-SC

[bluebill1049]

This is definitely one of my favorite features for performance improvement.

Currently, we are batching formState update in react-hook-form such as below:

const [formState, setFormState] = React.useState({
  isDirty: false,
  isTouched: false,
  touchedFields: [],
  ...
});

setFormState({
  ...formState,
  isTouched: true,
})

This is kind of close to batch update, except it has a problem with useEffect dep.

const { formState: { touchedFields } } = useForm()

useEffect(() => { console.log(touchedFields) }, [touchedFields]) // not working
useEffect(() => { console.log(formState.touchedFields) }, [formState]) // working, but it fire other formState gets affected as well

Just to validate my assumption, with this new release. we can do the following:

any sync state update will result in a single batch, but it will break the batch and result in multiple state updates with any async update.

const [isDirty, setIsDirty] = React.useState(false);
const [dirtyFields, setDirtyFields] = React.useState([]);

const Test = async () => {
  setIsDirty(true);
  
  // anything execution except async action, which will break the batch?
  
  setDirtyFields([1,2,3,4]);
}

[gaearon]

Sounds right to me but it depends on what you mean by "async action". Do you want to make a sandbox to dive deeper?

[bluebill1049]

Will do, thanks @gaearon.

[bluebill1049]

oh wow, it works. https://codesandbox.io/s/festive-smoke-228ny?file=/src/index.js 👯‍♂️

[devknoll]

Maybe @gaearon can correct me, but I don't think it's breaking the batch per se, but the promise happens to resolve after the batch has already started (or finished). I think if you had a smaller timeout in your example, or an already resolved promise, they would most likely get included in the same batch.

edit: except in the case of event handlers, since those updates are currently flushed in a microtask, so other async updates would only be included if they are queued before then.

[markerikson]

How does this affect the timing of state updates queued in the commit and passive effect phases?

My understanding is that currently:

• Updates queued in the commit phase (cDM/cDU/uLE) are executed synchronously
• Updates queued in the passive effects phase (useEffect callbacks) are deferred to the end of the effects phase

Any changes there?

[Andarist]

If it's inside flushSync or a discrete browser event, they'll run synchronously in a microtask.

Will those behave the same or is there any subtle difference? Can we think of discrete browser events as if their handlers would be wrapped with flushSync? Would you recommend libraries wrapping their handlers with flushSync if they listen for discrete events manually instead of relying on React event listeners? This is not super common but there are some situations when libraries do that (for example in React Aria, cc @devongovett )

If it's in startTransition, it will run concurrently in a normal task.

Could you describe in more detail what happens in such a case? Some short code snippet illustrating this would be helpful. Did this only refer to concurrent rendering that will happen in a normal task when scheduled from within startTransition or does it also have some effect on effects?

[rickhanlonii]

Would you recommend libraries wrapping their handlers with flushSync if they listen for discrete events manually instead of relying on React event listeners.

This shouldn't be necessary because we handle discrete events originating outside of the React event system the same way, by reading window.event. There may be some use cases that don't automatically work though, and for those you can use flushSync. It should be used sparingly though, because if it's done too much you'll just effectively force React back into sync mode.

Could you describe in more detail what happens in such a case?

We're working on a dedicated startTransition post, so we'll have more information there.

The short version is seen in this code:

function handleClick(e) {
  const query = e.target.value;

  // This will set the value synchronously in a microtask
  // since click events are "discrete". This allows for
  // typing to feel very responsive, because we defer
  // the more expensive update below.
  setInputValue(query);
  
  // This schedules a lower-priority update, rendered concurrently,
  // because it's a transition. This is nice because rendering the 
  // actual results can be expensive, and you don't want to block typing.
  startTransition(() => {
    setFilterBy(query);
  });
}

Any updates triggered inside of startTransition will be rendered at a lower priority, with time slicing, and the same will apply to any updates inside effects triggered by these updates. There are additional supsense-related semantics but we'll save that for the post.

[Andarist]

@rickhanlonii thank you for the answer - I think I somewhat understand this better now, although concurrent React is so different from what we have now that I still need to rewire my brain to see how all of this fits together.

The part that was fuzzy for me previously is that startTransition actually renders (and leads to a commit) immediately~ (otherwise isPending would be pretty useless if it couldn't be flushed to the screen) but yet its purpose is to also lead to some update that is going to be caught by a suspense boundary, which in turn will render concurrently. So the whole transition leads to two renders in a sense - one is "immediate" and the other one is potentially deferred.

---

I assume that if some lower priority update manages to schedule some non-discrete passive effects and a discrete update happens before they could be flushed then they will be flushed synchronously before new discrete passive effects are executed, right?

[rickhanlonii]

@markerikson @Andarist I've updated my comment above because I double checked and my information was out of date. We no longer "inherit" the priority of the original update, most of the time we just run them in a task at normal priority. To make the updates flush immediately, you can wrap them in flushSync.

[rickhanlonii]

but yet its purpose is to also lead to some update that is going to be caught by a suspense boundary

This is true, but not the only purpose. It's also useful for rendering CPU-bound updates (that don't suspend) because even if you don't suspend, we render the update concurrently, allowing high pri work (like additional key presses) to interrupt and be rendered before the slow update commits.

That's what's happening in the time-slicing demo here (notice that there's no suspense).

[alvarlagerlof]

What happens if a given logical batch takes longer than 5ms and there is other work do be done? Does it get split or paused then continued?

[gaearon]

This seems unrelated to batching to me — it sounds like a general question about rendering. For most state updates, we will do all the work synchronously and never interrupt it. The way you can opt into interruptions is with startTransition:

startTransition(() => {
  setState(something)
})

[shrutikapoor08]

This is because the state is being set "outside" the event handler (after it has already run):

It would be helpful to explain where the state is being set in this example and how it is "outside" the event handler. It can be confusing to the reader since it is happening inside the then method of the fetchSomething promise.

[gaearon]

Thanks! I removed “outside”. Is this rewording clearer?

This is because React used to only batch updates during a browser event (like click), but here we’re updating updating the state after the event has already been handled (in fetch callback):

[shrutikapoor08]

This is perfect! A typo crept in here but otherwise makes a lot more sense now. Thank you!

but here we’re updating updating the state after the event has already been handled (in fetch callback):

[gaearon]

Fixed!

[shaundai]

This is very well-explained, @gaearon! You are an incredible teacher.

One small thing that could be a little clearer in this example:

  function handleClick() {
    fetchSomething().then(() => {
-     // React 17 and earlier does NOT batch these:
+     // React 17 and earlier does NOT batch these because they are now inside a callback:
      setCount(c => c + 1); // Causes a re-render
      setFlag(f => !f); // Causes a re-render
    });
  }

or something like that! For the people who are new to batching, it may be confusing that setCount and setFlag aren't batched if they are technically inside handleClick.

[markerikson]

Perhaps something like this?

// React 17 and earlier does not batch these, because this section runs outside of the original event handler

or "after the original event handler" or something like that.

[gaearon]

Thank you @shaundai! (I can't take the full credit because we co-wrote this with @rickhanlonii and I mostly just did light editing!)

I did a small edit to address your point. Is it clearer?

[markerikson]

LGTM 👍

[shaundai]

Yes that's awesome! @gaearon

And @rickhanlonii is seriously amazing.

[markerikson]

One other question on the implementation and behavior here, because I may have had a mistaken impression:

Will React batch updates across multiple event loop ticks, or only within the same event loop tick?

As an example:

setState(1);

setTimeout(() => {
  setState(2)
}, 0)

Here these two state updates should be queued within a couple milliseconds of each other, but they occur in different event loop ticks because the second is inside a timeout.

I believe I saw a mention somewhere that React is now using "microtasks" to execute batched state updates at the end of one event loop tick, which suggests that this would still result in two separate renders. Can someone confirm the expected behavior?

I know I also saw a mention of "5ms" timing somewhere, but I think that was in reference to how long React will work before yielding back to the browser, and I may have misinterpreted that as "React will batch updates across ticks that occur within 5ms of each other".

[ad1992]

The updates outside setTimeout will be batched together and updates inside setTimeout will be batched together separately so it will be 2 separate renders.
As far as I understand since the code inside setTimeout is asynchronous and will be executed after some delay(until event loop pops from the task queue and pushes to the call stack) hence React will not be batching it.

I know I also saw a mention of "5ms" timing somewhere, but I think that was in reference to how long React will work before yielding back to the browser, and I may have misinterpreted that as "React will batch updates across ticks that occur within 5ms of each other".

I am not sure about the 5ms timing, but batching is n't related to queuing within 5ms as far as I understand, batching makes sure that app isn't rendered until it executes the whole callback. But If we use the concurrent api startTransition instead of setTimeout then the startTransition will be executed immediately and the updates inside it will be marked as transition which could be interrupted incase of some urgent update (click) kicking in.

Team could you confirm if the understanding is right ?

[chantastic]

I'm trying to understand the Class Component example using ReactDOM.flushSync

Should it be logging the partial update we see in the v17 version? As far as I can tell, the demo logs the the full state change { count: 1, flag: false }.

Am I missing the intent of flushSync in this context?

[gaearon]

As far as I can tell, the demo logs the the full state change { count: 1, flag: false }.

The flag is false initially. So { count: 1, flag: false } is not a full stage change. The full state change is { count: 1, flag: true }.

Without flushSync, that log shows { count: 0, flag: false }.

[chantastic]

Thanks, @gaearon!
I See now where my mistake was.
I'd created a demo that logged after both state changes. With the legacy root API, both logged different states. With the new root API, both logged the same. I realize now that — with createRoot — I would need to wrap both state changes in flushSync to see different logs.

handleClick = () => {
	setTimeout(() => {
		ReactDOM.flushSync(() => {
			this.setState(({ count }) => ({ count: count + 1 }));
		});

		// logs partial state change
		console.log(this.state);

		this.setState(({ isOdd }) => ({ isOdd: !isOdd }));

		// logs same partial state change
		// i'd need to wrap the above setState in flushSync to see an updated value here
		console.log(this.state);
	});
};

[gaearon]

Right, so you flushed the first setState but not the second one. (Before createRoot, all updates outside of event handlers were synchronous, so flushing didn't do anything—it was flushed during setState.)

[Shawkat-Roy]

Firstly, thank you so much for this info @gaearon , I really appreciate the clarity on batching, it's absolutely crucial information! I hope it's ok if I ask one more question in this old discussion.

React only batches updates when it’s generally safe to do. For example, React ensures that for each user-initiated event like a click or a keypress, the DOM is fully updated before the next event. This ensures, for example, that a form that disables on submit can’t be submitted twice.

I want to try to get extra confirmation on what assumptions can and can't be made about when state changes will take effect. This quote is really helpful but I still feel that I'm in the dark about state changes that don't happen from user initiated events e.g. setTimeout callbacks, promise callbacks etc. Basically, I just want to know when it is and isn't safe to read state and assume it's up to date. Clarity on any of the following would be amazing:

• In your quote are you referring to all user initiated events or just between multiple invokations of the same event?
  I.e. does the assumption only apply between clicks of the same button, or can I also assume that an onHover() state change will take effect before execution of a separate onClick() event that happens just after the onHover()?
• Can I assume that this.setState() will have fully taken effect by the end of any micro and macro task?
• Could react ever batch across multiple micro/macro tasks?
• At which points in the component lifecycle is it safe to assume that this.state will read perfectly up-to-date state?
  I assume that the very start of the render() function is one of them, and also the start of componentDidUpdate() (except for state changes that could have happened inside the preceeding render() call).
  Am I right here? Are there any other places I can assume this.state is up to date?

I saw your twitter posts from 2019 about mousemove being different, and you linked to a list of 'interactive' events which are those that we can assume will be flushed before the next event, but unfortunately that link is broken now so I can't see that list. Even if the link wasn't broken, I still wanted to ask, is any of this considered an implementation detail or can it be relied upon?

Apologies for the long question, but I really feel this is crucial information right? Without knowing when it is and isn't safe to read state, and assume it's up-to-date, I'm struggling to use react with confidence (although your confirmation on user initiated events really helped!)

[jan-krakora]

Can somebody give me an explanation how can React batch update states from asynchronous code like this? I mean how is it possible to know when the batch should be flushed already?

function handleClick() {
    fetchSomething().then(() => {
      // React 18 and later DOES batch these:
      setCount(c => c + 1);
      setFlag(f => !f);
      // React will only re-render once at the end (that's batching!)
    });
  }

Does React uses a timeout internally or something?

[Andarist]

My educated is that rerender is scheduled to happen in a microtask though queueMkcrotask API or using a MessageChannel and its ports (or some other API that lets u achieve this, those are just the common ones)

[kspshnik]

function handleClick() {
fetchSomething().then(() => {
.then() is supposed to be run upon resolve of the corresponding Promise, isn't it? In other words, when code inside .then() is executed, fetch() has already been successfully finished.