1 00:00:01,080 --> 00:00:03,180 ‫So we have dived really deep 2 00:00:03,180 --> 00:00:06,210 ‫into some aspects of the render phase, 3 00:00:06,210 --> 00:00:10,800 ‫like the rules for render logic, and how the key prop works. 4 00:00:10,800 --> 00:00:13,170 ‫But now let's take one step back, 5 00:00:13,170 --> 00:00:16,200 ‫and go back to one very important aspect 6 00:00:16,200 --> 00:00:18,660 ‫of the first triggering phase, 7 00:00:18,660 --> 00:00:23,231 ‫which is the fact that state updates are batched. 8 00:00:23,231 --> 00:00:27,900 ‫So in that first lecture about how rendering works, 9 00:00:27,900 --> 00:00:30,570 ‫we had this sentence, which says 10 00:00:30,570 --> 00:00:33,930 ‫that renders are not triggered immediately. 11 00:00:33,930 --> 00:00:37,770 ‫And so in this lecture I want to focus on this part 12 00:00:37,770 --> 00:00:40,740 ‫which says that there is also batching 13 00:00:40,740 --> 00:00:44,040 ‫of multiple setState calls. 14 00:00:44,040 --> 00:00:47,310 ‫Now, as always, the easiest way of explaining 15 00:00:47,310 --> 00:00:51,870 ‫difficult concepts is by using a small code example. 16 00:00:51,870 --> 00:00:54,660 ‫So here we have three pieces of state, 17 00:00:54,660 --> 00:00:57,210 ‫defined using the useState hook, 18 00:00:57,210 --> 00:01:00,900 ‫and we also have a button in the user interface. 19 00:01:00,900 --> 00:01:03,690 ‫Then whenever there is a click on the button, 20 00:01:03,690 --> 00:01:07,890 ‫the event handler function named reset is called. 21 00:01:07,890 --> 00:01:10,440 ‫In this function, the three pieces of state, 22 00:01:10,440 --> 00:01:13,350 ‫answer, best, and solved, 23 00:01:13,350 --> 00:01:17,430 ‫are basically reverted back to their original state 24 00:01:17,430 --> 00:01:20,700 ‫and therefore, this function is called reset. 25 00:01:20,700 --> 00:01:22,890 ‫Now, actually this is the part 26 00:01:22,890 --> 00:01:25,320 ‫that interests us in this lecture. 27 00:01:25,320 --> 00:01:30,090 ‫And so let's now focus only on the event handler function. 28 00:01:30,090 --> 00:01:32,940 ‫Now what I want to do here is to analyze 29 00:01:32,940 --> 00:01:35,280 ‫how these three pieces of state 30 00:01:35,280 --> 00:01:38,241 ‫are actually updated behind the scenes. 31 00:01:38,241 --> 00:01:41,550 ‫So we might think that, as React sees 32 00:01:41,550 --> 00:01:43,650 ‫the set answer function call, 33 00:01:43,650 --> 00:01:48,240 ‫it would update the state to the empty string as requested, 34 00:01:48,240 --> 00:01:52,260 ‫and then trigger a re-render, and the commit phase, 35 00:01:52,260 --> 00:01:54,900 ‫then it would move on to the next line, 36 00:01:54,900 --> 00:01:57,240 ‫and to the same thing again, 37 00:01:57,240 --> 00:01:59,250 ‫and finally do the entire thing 38 00:01:59,250 --> 00:02:03,180 ‫one more time for the third state update. 39 00:02:03,180 --> 00:02:05,850 ‫So intuitively, we would think that, 40 00:02:05,850 --> 00:02:08,100 ‫if there are three state variables 41 00:02:08,100 --> 00:02:10,530 ‫being updated in this event handler, 42 00:02:10,530 --> 00:02:14,940 ‫then React would re-render three times, right? 43 00:02:14,940 --> 00:02:18,750 ‫However, this is actually not how it works. 44 00:02:18,750 --> 00:02:23,100 ‫So this is not how React updates multiple pieces of state 45 00:02:23,100 --> 00:02:25,470 ‫in the same event handler function. 46 00:02:25,470 --> 00:02:29,280 ‫Instead, these state updates will actually get batched 47 00:02:29,280 --> 00:02:34,015 ‫into just one state update for the entire event handler. 48 00:02:34,015 --> 00:02:37,020 ‫So updating multiple pieces of state 49 00:02:37,020 --> 00:02:40,920 ‫won't immediately cause a re-render for each update. 50 00:02:40,920 --> 00:02:44,580 ‫Instead, all pieces of state inside the event handler 51 00:02:44,580 --> 00:02:46,800 ‫are updated in one go. 52 00:02:46,800 --> 00:02:49,830 ‫So they are batched, and only then 53 00:02:49,830 --> 00:02:54,420 ‫will React trigger one single render and commit. 54 00:02:54,420 --> 00:02:58,890 ‫And conceptually, it makes sense that React works this way, 55 00:02:58,890 --> 00:03:02,490 ‫because if we're updating these pieces of state together, 56 00:03:02,490 --> 00:03:05,340 ‫it probably means that they should just represent 57 00:03:05,340 --> 00:03:07,710 ‫one new view, and therefore, 58 00:03:07,710 --> 00:03:10,999 ‫React only updates the screen once. 59 00:03:10,999 --> 00:03:14,490 ‫So if these date updates belong together, 60 00:03:14,490 --> 00:03:16,500 ‫it really wouldn't make much sense 61 00:03:16,500 --> 00:03:19,320 ‫to update the screen three times. 62 00:03:19,320 --> 00:03:23,430 ‫Doing so would also create two wasted renders, 63 00:03:23,430 --> 00:03:26,760 ‫because we're not interested in the first two renders, 64 00:03:26,760 --> 00:03:29,418 ‫only the final one, which already contains 65 00:03:29,418 --> 00:03:32,070 ‫all the three state updates. 66 00:03:32,070 --> 00:03:34,200 ‫Therefore, the fact that React 67 00:03:34,200 --> 00:03:37,560 ‫automatically batches state updates in this way 68 00:03:37,560 --> 00:03:40,290 ‫is yet another performance optimization 69 00:03:40,290 --> 00:03:43,710 ‫that React gives us out of the box. 70 00:03:43,710 --> 00:03:47,190 ‫Now, batching state updates is extremely useful, 71 00:03:47,190 --> 00:03:50,119 ‫but it can also have surprising results. 72 00:03:50,119 --> 00:03:54,210 ‫So let's turn our attention to this line of code now, 73 00:03:54,210 --> 00:03:57,270 ‫where we reference the answer state variable 74 00:03:57,270 --> 00:03:59,730 ‫right after updating it. 75 00:03:59,730 --> 00:04:02,040 ‫So what do you think will be the value 76 00:04:02,040 --> 00:04:04,776 ‫of this variable at this point? 77 00:04:04,776 --> 00:04:07,795 ‫Well, let's try to think about this. 78 00:04:07,795 --> 00:04:11,640 ‫So remember, that component state is stored 79 00:04:11,640 --> 00:04:15,390 ‫in the fiber tree during the render phase. 80 00:04:15,390 --> 00:04:17,190 ‫Now, at this point in the code, 81 00:04:17,190 --> 00:04:20,220 ‫the render phase has not happened yet. 82 00:04:20,220 --> 00:04:24,030 ‫So React is still reading the function line by line 83 00:04:24,030 --> 00:04:27,270 ‫to figure out what state needs to be updated, 84 00:04:27,270 --> 00:04:30,510 ‫but it hasn't actually updated the state yet, 85 00:04:30,510 --> 00:04:33,720 ‫and it also hasn't re-rendered yet. 86 00:04:33,720 --> 00:04:36,480 ‫That's the whole point of batching state updates 87 00:04:36,480 --> 00:04:38,556 ‫in the first place, right? 88 00:04:38,556 --> 00:04:43,350 ‫So what this means is that, at this point of the code, 89 00:04:43,350 --> 00:04:47,370 ‫the answer variable will still hold the current state. 90 00:04:47,370 --> 00:04:50,100 ‫So the state before the update, 91 00:04:50,100 --> 00:04:53,776 ‫even though we already told React to update it. 92 00:04:53,776 --> 00:04:58,470 ‫So at this point we say that our state is stale, 93 00:04:58,470 --> 00:05:02,610 ‫meaning that the state is no longer fresh and updated, 94 00:05:02,610 --> 00:05:06,870 ‫because in fact, a state update will only be reflected 95 00:05:06,870 --> 00:05:10,110 ‫in the state variable after the re-render. 96 00:05:10,110 --> 00:05:14,610 ‫And so for this reason, we say that updating state in React 97 00:05:14,610 --> 00:05:19,560 ‫is asynchronous, and again, it is asynchronous 98 00:05:19,560 --> 00:05:23,614 ‫because React does not give us the updated state variable 99 00:05:23,614 --> 00:05:26,760 ‫immediately after the set answer call, 100 00:05:26,760 --> 00:05:30,183 ‫but only after the re-render has happened. 101 00:05:31,140 --> 00:05:33,600 ‫Now, the same thing is also true 102 00:05:33,600 --> 00:05:37,499 ‫whenever there is only one piece of state being updated. 103 00:05:37,499 --> 00:05:41,940 ‫So no matter how many state variables are being updated, 104 00:05:41,940 --> 00:05:44,550 ‫the updated state is only available 105 00:05:44,550 --> 00:05:47,977 ‫after the re-render, not immediately. 106 00:05:47,977 --> 00:05:52,110 ‫Now, sometimes we actually do need the new value 107 00:05:52,110 --> 00:05:56,255 ‫immediately after updating it, and in the case, 108 00:05:56,255 --> 00:05:57,270 ‫that we need the new value 109 00:05:57,270 --> 00:06:00,240 ‫in order to update the same state again. 110 00:06:00,240 --> 00:06:03,990 ‫Or in other words, if we need to update state based 111 00:06:03,990 --> 00:06:07,560 ‫on a previous state update in the same event handler, 112 00:06:07,560 --> 00:06:11,730 ‫we can pass a callback function into the set state function 113 00:06:11,730 --> 00:06:13,860 ‫instead of a single value. 114 00:06:13,860 --> 00:06:16,110 ‫And we have actually done this in practice 115 00:06:16,110 --> 00:06:18,033 ‫all the time, right? 116 00:06:20,160 --> 00:06:23,460 ‫Now, so far, we have only talked about batching 117 00:06:23,460 --> 00:06:27,930 ‫in event handler functions, like our reset function. 118 00:06:27,930 --> 00:06:30,600 ‫That's because before React 18, 119 00:06:30,600 --> 00:06:34,770 ‫React only did automatic batching in event handlers, 120 00:06:34,770 --> 00:06:37,080 ‫but not in situations that happen 121 00:06:37,080 --> 00:06:40,320 ‫after a browser event has already happened. 122 00:06:40,320 --> 00:06:43,530 ‫However, there are certain very important situations 123 00:06:43,530 --> 00:06:46,410 ‫in which we do need to update state, 124 00:06:46,410 --> 00:06:50,850 ‫long after a browser event, like a click, has happened. 125 00:06:50,850 --> 00:06:54,932 ‫Examples of that are timeouts and promises, 126 00:06:54,932 --> 00:06:59,190 ‫for instance, we might want to run our reset function 127 00:06:59,190 --> 00:07:01,920 ‫only a second after a click event, 128 00:07:01,920 --> 00:07:06,360 ‫or we might want to run it after some data has been fetched. 129 00:07:06,360 --> 00:07:09,750 ‫So it would be nice to also have automatic batching 130 00:07:09,750 --> 00:07:14,190 ‫in those situations to improve performance, right? 131 00:07:14,190 --> 00:07:17,520 ‫Well, that's actually one of the important features 132 00:07:17,520 --> 00:07:20,400 ‫that React 18 gave us. 133 00:07:20,400 --> 00:07:24,090 ‫So before React 18, if this reset function 134 00:07:24,090 --> 00:07:27,330 ‫was called by a timeout, or by a promise, 135 00:07:27,330 --> 00:07:31,800 ‫state updates inside the function would not be batched. 136 00:07:31,800 --> 00:07:35,250 ‫Instead, in these situations, React would actually 137 00:07:35,250 --> 00:07:39,330 ‫update the state variables one by one, and therefore, 138 00:07:39,330 --> 00:07:42,480 ‫in this case, render three times. 139 00:07:42,480 --> 00:07:46,710 ‫Now another case is handling native events using DOM methods 140 00:07:46,710 --> 00:07:50,160 ‫such as addEventListener, where state updates 141 00:07:50,160 --> 00:07:54,660 ‫also used to not be batched, but now they are. 142 00:07:54,660 --> 00:07:58,140 ‫So again, if you're using the latest React version, 143 00:07:58,140 --> 00:08:01,470 ‫you will now get automatic batching all the time, 144 00:08:01,470 --> 00:08:03,690 ‫everywhere in your code. 145 00:08:03,690 --> 00:08:06,300 ‫And if, for some reason, you are working 146 00:08:06,300 --> 00:08:09,900 ‫with an older version of React, maybe at your work, 147 00:08:09,900 --> 00:08:13,170 ‫it's important that you know that batching used to work 148 00:08:13,170 --> 00:08:16,560 ‫in a different way before version 18. 149 00:08:16,560 --> 00:08:19,830 ‫Now, there are also some extremely rare situations 150 00:08:19,830 --> 00:08:23,340 ‫in which automatic batching can be problematic. 151 00:08:23,340 --> 00:08:26,790 ‫So if you ever find yourself in a situation like that, 152 00:08:26,790 --> 00:08:29,730 ‫you can just wrap the problematic state update 153 00:08:29,730 --> 00:08:33,630 ‫in a ReactDOM.flushSync function, 154 00:08:33,630 --> 00:08:37,980 ‫and React will then exclude that update from batching. 155 00:08:37,980 --> 00:08:40,650 ‫But you will most likely never need this. 156 00:08:40,650 --> 00:08:42,150 ‫I'm just mentioning this here, 157 00:08:42,150 --> 00:08:44,873 ‫so that you know that it exists. 158 00:08:44,873 --> 00:08:49,800 ‫Now, okay, and that's it about state update batching. 159 00:08:49,800 --> 00:08:53,160 ‫It turned out to be a bit longer than I thought, 160 00:08:53,160 --> 00:08:54,960 ‫but as always, there is just 161 00:08:54,960 --> 00:08:57,420 ‫so much interesting stuff to learn, 162 00:08:57,420 --> 00:09:00,780 ‫and so I hope that you don't mind at all. 163 00:09:00,780 --> 00:09:04,320 ‫But in any case, let's quickly go to the next video, 164 00:09:04,320 --> 00:09:07,473 ‫so I can show you some of this in practice.