This course has been updated! We now recommend you take the React Performance course.

Check out a free preview of the full State Management in Pure React, v2 course:
The "setState & Asynchronicity" Lesson is part of the full, State Management in Pure React, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve explains that setState runs asynchronously, because react avoids unnecessary re-renders. If multiple cases of the same class containing setState are called multiple times, the last call will be the one executed.

Get Unlimited Access Now

Transcript from the "setState & Asynchronicity" Lesson

>> Now, this is all a giant trick to kinda set us up with a little laboratory to start diving in a little bit deeper into how some of this stuff works. So let's do a little bit of a pop quiz. You're like, great. All right, so this is the kinda simple version of the counter that we just implemented.

[00:00:22] I almost said incremented because counters. So we've got this counter with an initial state of 0. And let's say, in that increment method, we're like, cool. We're gonna call this.setState three times, each incrementing by 1. And then in that same method, in the increment method, we're gonna immediately console log it.

[00:00:47] What am I gonna get console logged at that point?
>> 0.
>> 0, right, we'll not get it three times just cuz we called it three times. In fact, we won't even get one, right? Because it's asynchronous, right? We don't wanna do on every line, they changed the state, let me stop the world, re-render the entire DOM.

[00:01:06] Let's let the function run to completion. Let's queue up everything they wanted to do. Let's figure out all of the changes that happened, right? And then React will be able to go in and figure out what changes it needs to make to the DOM in order to do its job, right?

[00:01:20] React is basically trying to avoid unnecessary re-renders. Okay, great, so we know that that will go ahead and do the trick. Now, assume we have the whole increment method in there, right? And we called it three times, same as before. Now we don't care about the console log.

[00:01:38] We wanna know what's gonna show up on the screen, right? Cuz we knew it's asynchronous. We knew nothing was gonna happen until after that happened, and then it can go through reconciliation. It can go check all the DOM nodes and the tree. But we're gonna say, we called it three times.

[00:01:53] Now we wanna know, after all the reconciliation is done, what is going to be on the screen as the count after all of reconciliation, the DOM is updated, ready? I see some people holding up fingers. 1, right, the reason for this is that we're effectively queuing upstate changes, right?

[00:02:15] And so we're basically, kind of the way to think about it is we told React, okay, I would love you to set the state to the current state, which is 0, plus 1. And we basically said that three times, right? Set it to 0 plus 1, set it to 0 plus 1, set it to 0 plus 1.

[00:02:31] And so it's like, okay, I got it, neat. Thank you for that. And then it set it to 0 plus 1 the third time. It effectively goes out and tries to collect all of the things in that object. Now this is gonna be different when we get to hooks a little bit, right?

[00:02:44] Cuz when we get to hooks, there are no objects per se, but it's effectively taking all of those. When we say this.setState, we give it an object. In this case, it had the key of count and the value of what the new count should be. And it merges all those objects together.

[00:02:58] So if we had all sort of other things and we had multiple this.setStates, it would find all of the keys, and basically it merges them and there's duplicate keys, the last one wins, right? So if we went in there and we said count is this.state.count + 1, + 1, and then the third one instead + 2, well, that one's gonna win.

[00:03:17] It's actually gonna increment by 2. It's like whatever happens last wins. So if you're calling in multiple cases, and in a very simple example, why would I do that? Well, we all know we all have at least one part of our application that has one of those hundred line methods in there.

[00:03:32] It doesn't happen in a five line method, it happens in the hundred line method. And when you're sitting there, cuz you're not gonna get an error message right. Nothing went wrong. It was just following the rules in a way that you weren't totally expecting yet. So understanding that, cuz when you get an error message, it might feel like your heart is broken when you see all that red on the screen, but at least there's some line numbers.

[00:03:53] The worst things are when nothing happens, it just doesn't do the thing that you expected, right? And so understanding how some of the inner workings goes a really long way. So you can use Object.assign. It's effectively this if you like the hipster spread notation, I do, says the guy wearing plaid and a beanie.