Why does Async Await work with React setState?

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…)

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

5. 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

6. your validation code runs

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.