Let's talk in detail about whether setState in React is a macro task or a micro task

Preface

Recently a friend of mine had an interview and the interviewer asked a weird question, which is the question I wrote in the title.

The interviewer probably doesn’t know much about React if he asks this question. It may also be because he saw that the candidate wrote in his resume that he is familiar with React, and the interviewer wants to use this question to judge whether the candidate is really familiar with React 🤣.

Is the interviewer asking the right questions? §

The interviewer's question is whether setState is a macrotask or a microtask. In his opinion, setState must be an asynchronous operation. In order to determine whether setState is an asynchronous operation, you can do an experiment first. Create a new React project through CRA and edit the following code in the project:

import React from 'react';
import logo from './logo.svg';
import './App.css';

class App extends React.Component {
  state = {
    count: 1000
  }
  render() {
    return (
      <div className="App">
        <img
          src={logo} alt="logo"
          className="App-logo"
          onClick={this.handleClick}
        />
        <p>My followers: {this.state.count}</p>
      </div>
    );
  }
}

export default App;

The page probably looks like this:

The React Logo above is bound to a click event. Now we need to implement this click event. After clicking the Logo, perform a setState operation, print a log when the set operation is completed, and add a macro task and micro task before the set operation. The code is as follows:

handleClick = () => {
  const fans = Math.floor(Math.random() * 10)
  setTimeout(() => {
    console.log('macro task triggered')
  })
  Promise.resolve().then(() => {
    console.log('microtask trigger')
  })
  this.setState({
    count: this.state.count + fans
  }, () => {
    console.log('New fans:', fans)
  })
}

Obviously, after clicking the Logo, the setState operation is completed first, and then the microtask and macrotask are triggered. Therefore, the execution time of setState is earlier than microtasks and macrotasks. Even so, it can only be said that its execution time is earlier than Promise.then, which cannot prove that it is a synchronous task.

handleClick = () => {
  const fans = Math.floor(Math.random() * 10)
  console.log('Start running')
  this.setState({
    count: this.state.count + fans
  }, () => {
    console.log('New fans:', fans)
  })
  console.log('End of run')
}

From this perspective, it seems that setState is also an asynchronous operation. The main reason is that in the life cycle of React and the bound event flow, all setState operations will be cached in a queue first. After the entire event is over or the mount process is over, the previously cached setState queue will be taken out for calculation to trigger a state update. As long as we jump out of React's event flow or life cycle, we can break React's control over setState. The simplest way is to put setState into the anonymous function of setTimeout.

handleClick = () => {
  setTimeout(() => {
    const fans = Math.floor(Math.random() * 10)
    console.log('Start running')
    this.setState({
      count: this.state.count + fans
    }, () => {
      console.log('New fans:', fans)
    })
    console.log('End of run')
  })
}

It can be seen that setState is essentially still in an event loop and has not switched to another macrotask or microtask. It is implemented based on synchronous code in operation, but it looks like asynchronous behavior. So, there is no question of the interviewer at all.

How does React control setState? §

In the previous case, setState becomes like a synchronous method only in setTimeout. How is this done?

handleClick = () => {
  // Normal operation this.setState({
    count: this.state.count + 1
  })
}
handleClick = () => {
  // Operation out of React control setTimeout(() => {
    this.setState({
      count: this.state.count + fans
    })
  })
}

Let's review the previous code. In these two operations, we record the call stack once in Performance respectively to see the difference between the two call stacks.

In the call stack, you can see that the Component.setState method will eventually call the enqueueSetState method, and the enqueueSetState method will call the scheduleUpdateOnFiber method. The difference is that during normal calls, the scheduleUpdateOnFiber method will only call ensureRootIsScheduled, and the flushSyncCallbackQueue method will be called after the event method ends. When leaving the React event flow, scheduleUpdateOnFiber will directly call the flushSyncCallbackQueue method after the ensureRootIsScheduled call is completed. This method is used to update the state and re-render.

function scheduleUpdateOnFiber(fiber, lane, eventTime) {
  if (lane === SyncLane) {
    // Synchronous operation ensureRootIsScheduled(root, eventTime);
    // Check if it is still in the React event stream // If not, directly call flushSyncCallbackQueue to update if (executionContext === NoContext) {
      flushSyncCallbackQueue();
    }
  } else {
    // Asynchronous operation}
}

The above code can simply describe this process, which mainly determines whether the executionContext is equal to NoContext to determine whether the current update process is in the React event flow.

As we all know, when React binds events, it synthesizes the events and binds them to the document (react@17 has changed to bind the events to the DOM element specified when rendering), and finally React dispatches them.

When all events are triggered, the batchedEventUpdates$1 method will be called first, where the value of executionContext will be modified, and React will know that setState is under its control at this time.

//Default state of executionContext var executionContext = NoContext;
function batchedEventUpdates$1(fn, a) {
  var prevExecutionContext = executionContext;
  executionContext |= EventContext; // Modify status try {
    return fn(a);
  finally
    executionContext = prevExecutionContext;
    // After the call is completed, call flushSyncCallbackQueue
    if (executionContext === NoContext) {
      flushSyncCallbackQueue();
    }
  }
}

Therefore, whether you call flushSyncCallbackQueue directly or postpone the call, it is essentially synchronous, but there is a question of sequence.

There will be asynchronous setState in the future§

If you look carefully at the code above, you will find that in the scheduleUpdateOnFiber method, it will determine whether the lane is synchronous, so is there an asynchronous situation?

function scheduleUpdateOnFiber(fiber, lane, eventTime) {
  if (lane === SyncLane) {
    // Synchronous operation ensureRootIsScheduled(root, eventTime);
    // Check if it is still in the React event stream // If not, directly call flushSyncCallbackQueue to update if (executionContext === NoContext) {
      flushSyncCallbackQueue();
    }
  } else {
    // Asynchronous operation}
}

When React upgraded its fiber architecture two years ago, it was preparing for its asynchrony. The Concurrent mode will be officially released in React 18. The official introduction to the Concurrent mode is as follows.

What is Concurrent Mode?

Concurrent Mode is a set of new React features that help apps stay responsive and scale appropriately based on the user's device capabilities and network speed. In Concurrent Mode, rendering is non-blocking. It is interruptible. This improves the user experience. It also unlocks new capabilities that were not possible before.

If you want to use Concurrent Mode now, you need to use the experimental version of React. If you are interested in this part, you can read my previous article: https://blog.shenfq.com/posts/2020/React%20The Evolution of Architecture%20-%20From Synchronous to Asynchronous.html

Summarize

This concludes this article on whether setState in React is a macrotask or a microtask. For more information on whether setState in React is a macrotask or a microtask, please search previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!