Why does Async Await work with React setState?

38
votes

I have been using async await with babel in my ReactJS project. I discovered a convenient use with React setState that I would just like to understand better. Consider this code:

handleChange = (e) => {
  this.setState({[e.target.name]: e.target.value})
  console.log('synchronous code')
}

changeAndValidate = async (e) => {
  await this.handleChange(e)
  console.log('asynchronous validation code')
}

componentDidUpdate() {
  console.log('updated component')    
}

My intention was for the asynchronous validation code to run after the component has updated. And it works! The resulting console log shows:

synchronous code
updated component
asynchronous validation code

The validation code will only run after handleChange has updated the state and the new state is rendered.

Usually to run code after state has updated, you would have to use a callback after this.setState. Which means if you want to run anything after handleChange, you have to give it a callback parameter which is then passed to setState. Not pretty. But in the code example, somehow await knows that handleChange is complete after the state has updated... But I thought await only works with promises and waits for a promise to resolve before continuing. Theres no promise and no resolution in handleChange... How does it know what to wait for??

The implication seems to be that setState is run asynchronously and await is somehow aware of when it completes. Maybe setState uses promises internally?

Versions:

react: "^15.4.2"

babel-core: "^6.26.0"

babel-preset-env: "^1.6.0",

babel-preset-react: "^6.24.1",

babel-preset-stage-0: "^6.24.1"

babel-plugin-system-import-transformer: "^3.1.0",

babel-plugin-transform-decorators-legacy: "^1.3.4",

babel-plugin-transform-runtime: "^6.23.0"

4
reactjsasync-awaitbabeljs
The code above has an await on undefined (because handleChange doesn't return anything). Are you sure it is having an effect on setState? – Davin Tryon
what version of React and babel are you using? – Davin Tryon
that's weird, but i confirm await have effect. await this.setState({ data: true }, () => console.log('callback')); console.log('inline'); clearly says callback will be fired first, however - remove await and works as usually setState suppose to work - inline first and then callback – Vlad
@DavinTryon seems to be correct, you should turn it into an answer it would be helpful for others in the future as well as this is a pretty common search – linasmnew
I would like some elaboration too. Is the undefined returned by setState asynchronous? Does it always return after the component updates? – Leo Fabrikant

4 Answers

47
votes

I tried to do my best to simplify and complement Davin's answer, so you can get a better idea of what is actually going on here:

  1. await is placed in front of this.handleChange, this will schedule the execution of the rest of changeAndValidate function to only run when await resolves the value specified to the right of it, in this case the value returned by this.handleChange

  2. this.handleChange, on the right of await, executes:

    2.1. setState runs its updater but because setState does not guarantee to update immediately it potentially schedules the update to happen at a later time (it doesn't matter if it's immediate or at a later point in time, all that matters is that it's scheduled)

    2.2. console.log('synchronous code') runs...

    2.3. this.handleChange then exits returning undefined (returns undefined because functions return undefined unless explicitly specified otherwise)

  3. await then takes this undefined and since it's not a promise it converts it into a resolved promise, using Promise.resolve(undefined) and waits for it - it's not immediately available because behind the scenes it gets passed to its .then method which is asynchronous:

“Callbacks passed into a promise will never be called before the completion of the current run of the JavaScript event loop”

3.1. this means that undefined will get placed into the back of the event queue, (which means it’s now behind our setState updater in the event queue…)

  1. event loop finally reaches and picks up our setState update, which now executes...

  2. event loop reaches and picks up undefined, which evaluates to undefined (we could store this if we wanted, hence the = commonly used in front of await to store the resolved result)

    5.1. Promise.resolve() is now finished, which means await is no longer in affect, so the rest of the function can resume

  3. your validation code runs
5
votes

I haven't tested this yet, but here is what I think is happening:

The undefined returned by await is queued after the setState callback. The await is doing a Promise.resolve underneath (in the regenerator-runtime) which in turn yields control to the next item on the event loop.

So, it is coincidence that the setState callback happens to be queued ahead of the await.

You can test this by putting a setTimeout(f => f, 0) around the setState.

regenerator-runtime in babel is essentially a loop that uses Promise.resolve to yield control. You can see the inside the _asyncToGenerator, it has a Promise.resolve.

4
votes

setState() does not always immediately update the component doc

But it may be the case here.

If you want to replace the callback with a promise you can implement it yourself :

setStateAsync(state) {
  return new Promise((resolve) => {
    this.setState(state, resolve)
  });
}

handleChange = (e) => {
  return this.setStateAsync({[e.target.name]: e.target.value})
}

ref : https://medium.com/front-end-hacking/async-await-with-react-lifecycle-methods-802e7760d802

1
votes

The rv or return value of await is defined as:

rv
Returns the fulfilled value of the promise, or the value itself if it's not a Promise.

So since handleChange is not an async or promise value, it's simply returning the natural value (in this case, there is no return, so undefined). Thus, there is no async event loop trigger here to "let it know handleChange is done", it simply just runs in the order you have given it.