1 00:00:00,800 --> 00:00:03,780 ‫Welcome back to part three 2 00:00:03,780 --> 00:00:06,393 ‫of How Rendering Works Behind the Scenes. 3 00:00:07,650 --> 00:00:11,250 ‫So we just finished learning about the render phase 4 00:00:11,250 --> 00:00:14,176 ‫which resulted in a list of DOM updates 5 00:00:14,176 --> 00:00:18,882 ‫and this list will now get used in the commit phase. 6 00:00:18,882 --> 00:00:22,710 ‫Now, technically speaking, the current work in progress 7 00:00:22,710 --> 00:00:25,931 ‫fiber tree also goes into this commit phase, 8 00:00:25,931 --> 00:00:28,260 ‫but let's keep it simple here. 9 00:00:28,260 --> 00:00:30,570 ‫So these are more conceptual diagrams 10 00:00:30,570 --> 00:00:33,450 ‫so that we can understand what is happening, 11 00:00:33,450 --> 00:00:36,270 ‫not a 100% accurate description 12 00:00:36,270 --> 00:00:40,470 ‫of the algorithms inside React, all right? 13 00:00:40,470 --> 00:00:43,050 ‫But anyway, as you know by now, 14 00:00:43,050 --> 00:00:47,580 ‫the commit phase is where React finally writes to the DOM, 15 00:00:47,580 --> 00:00:52,560 ‫so it inserts, deletes and updates DOM elements. 16 00:00:52,560 --> 00:00:54,150 ‫You'll sometimes also read 17 00:00:54,150 --> 00:00:58,500 ‫that React flushes updates to the DOM in this phase. 18 00:00:58,500 --> 00:01:01,800 ‫So basically, React goes through the effects list 19 00:01:01,800 --> 00:01:04,110 ‫that was created during rendering, 20 00:01:04,110 --> 00:01:07,890 ‫and applies them one by one to the actual DOM elements 21 00:01:07,890 --> 00:01:10,893 ‫that were in the already existing DOM tree. 22 00:01:11,850 --> 00:01:16,200 ‫Now riding to the DOM happens all in one go. 23 00:01:16,200 --> 00:01:19,800 ‫So we say that the commit phase is synchronous 24 00:01:19,800 --> 00:01:23,280 ‫unlike the rendering phase, which can be paused. 25 00:01:23,280 --> 00:01:26,202 ‫So committing cannot be interrupted. 26 00:01:26,202 --> 00:01:28,800 ‫Now this is necessary so that the DOM 27 00:01:28,800 --> 00:01:31,080 ‫never shows partial results 28 00:01:31,080 --> 00:01:35,070 ‫which ensures that the UI always stays consistent. 29 00:01:35,070 --> 00:01:38,100 ‫In fact, that's the whole point of dividing 30 00:01:38,100 --> 00:01:41,040 ‫the entire process into the render phase 31 00:01:41,040 --> 00:01:43,710 ‫and the commit phase in the first place. 32 00:01:43,710 --> 00:01:48,000 ‫It's so that rendering can be paused, resumed, and discarded 33 00:01:48,000 --> 00:01:50,700 ‫and the results of all that rendering 34 00:01:50,700 --> 00:01:54,270 ‫can then be flushed to the DOM in one go. 35 00:01:54,270 --> 00:01:57,090 ‫Then once the commit phase is completed, 36 00:01:57,090 --> 00:02:00,090 ‫the work in progress fiber tree becomes 37 00:02:00,090 --> 00:02:03,570 ‫the current tree for the next render cycle. 38 00:02:03,570 --> 00:02:07,980 ‫That's because, remember, fiber trees are never discarded 39 00:02:07,980 --> 00:02:10,650 ‫and never recreated from scratch. 40 00:02:10,650 --> 00:02:12,630 ‫Instead, they are reused 41 00:02:12,630 --> 00:02:15,930 ‫in order to save precious rendering time. 42 00:02:15,930 --> 00:02:19,410 ‫And with that, we close up the commit phase. 43 00:02:19,410 --> 00:02:22,890 ‫The browser will then notice that the DOM has been changed, 44 00:02:22,890 --> 00:02:26,040 ‫and as a result, it will repaint the screen 45 00:02:26,040 --> 00:02:29,070 ‫whenever it has some idle time. 46 00:02:29,070 --> 00:02:32,655 ‫So this is where these DOM updates are finally made visible 47 00:02:32,655 --> 00:02:37,655 ‫to the user in the form of an updated user interface. 48 00:02:38,130 --> 00:02:41,340 ‫Now, I'm not gonna go into how this phase works 49 00:02:41,340 --> 00:02:42,990 ‫because this is really more 50 00:02:42,990 --> 00:02:47,310 ‫about how browsers work internally, and not React. 51 00:02:47,310 --> 00:02:49,650 ‫However, there's still one more thing 52 00:02:49,650 --> 00:02:51,780 ‫that we need to talk about. 53 00:02:51,780 --> 00:02:54,870 ‫So the browser paint face that we just mentioned 54 00:02:54,870 --> 00:02:56,490 ‫is of course performed 55 00:02:56,490 --> 00:02:59,340 ‫by whatever browser the user is using. 56 00:02:59,340 --> 00:03:02,400 ‫And the render phase is obviously performed 57 00:03:02,400 --> 00:03:04,470 ‫by the React Library. 58 00:03:04,470 --> 00:03:06,930 ‫But what about the commit phase? 59 00:03:06,930 --> 00:03:11,700 ‫We would think that it's also done by React, right? 60 00:03:11,700 --> 00:03:14,910 ‫But actually that's not true. 61 00:03:14,910 --> 00:03:18,810 ‫It's actually a separate library that writes to the DOM, 62 00:03:18,810 --> 00:03:21,780 ‫and it's called React DOM. 63 00:03:21,780 --> 00:03:26,250 ‫So not very creative, but that's just what it's called. 64 00:03:26,250 --> 00:03:30,900 ‫So in fact, React itself does never touch the DOM, 65 00:03:30,900 --> 00:03:33,990 ‫and it actually has no idea where the result 66 00:03:33,990 --> 00:03:38,580 ‫of the render phase will actually be committed and painted. 67 00:03:38,580 --> 00:03:41,460 ‫So React only does the render phase 68 00:03:41,460 --> 00:03:43,680 ‫but not the commit phase. 69 00:03:43,680 --> 00:03:45,123 ‫And the reason for that is 70 00:03:45,123 --> 00:03:49,320 ‫that React itself was designed to be used independently 71 00:03:49,320 --> 00:03:53,310 ‫from the platform where elements will actually be shown, 72 00:03:53,310 --> 00:03:55,110 ‫and therefore React can be used 73 00:03:55,110 --> 00:03:57,963 ‫with many different so-called hosts. 74 00:03:58,890 --> 00:04:01,770 ‫Now up until this point, we have only ever thought 75 00:04:01,770 --> 00:04:04,560 ‫of React in conjunction with a DOM 76 00:04:04,560 --> 00:04:07,830 ‫because we usually use it to build web application. 77 00:04:07,830 --> 00:04:09,900 ‫And in 90% of the cases, 78 00:04:09,900 --> 00:04:12,570 ‫that's actually what we do with React. 79 00:04:12,570 --> 00:04:13,860 ‫But the truth is 80 00:04:13,860 --> 00:04:17,190 ‫that React is used with other hosts as well. 81 00:04:17,190 --> 00:04:19,080 ‫For example, we can actually build 82 00:04:19,080 --> 00:04:22,800 ‫native mobile applications for iOS and Android 83 00:04:22,800 --> 00:04:27,630 ‫using React Native, or we can build videos with React 84 00:04:27,630 --> 00:04:30,060 ‫using a package called Remotion. 85 00:04:30,060 --> 00:04:33,120 ‫And we can even create all kinds of documents 86 00:04:33,120 --> 00:04:37,020 ‫like Word or PDF documents, Figma designs 87 00:04:37,020 --> 00:04:41,940 ‫and many more, using different so-called renderers. 88 00:04:41,940 --> 00:04:43,830 ‫Now, if we think about this, 89 00:04:43,830 --> 00:04:47,460 ‫Renderer is actually a pretty terrible name 90 00:04:47,460 --> 00:04:50,640 ‫because according to React's own terminology, 91 00:04:50,640 --> 00:04:52,980 ‫Renderers do not render, 92 00:04:52,980 --> 00:04:56,490 ‫but they commit the results of the render phase. 93 00:04:56,490 --> 00:04:59,130 ‫But I think that this Renderer name 94 00:04:59,130 --> 00:05:01,650 ‫comes from a time before React divided 95 00:05:01,650 --> 00:05:05,880 ‫the render and the commit phase into two separate phases. 96 00:05:05,880 --> 00:05:08,970 ‫And so they chose this term of Renderer 97 00:05:08,970 --> 00:05:11,040 ‫because it fits with the common sense 98 00:05:11,040 --> 00:05:13,023 ‫definition of rendering. 99 00:05:13,860 --> 00:05:16,800 ‫But anyway, in all these situations, 100 00:05:16,800 --> 00:05:18,870 ‫the results of the render phase 101 00:05:18,870 --> 00:05:21,840 ‫is not really a list of DOM updates, 102 00:05:21,840 --> 00:05:24,900 ‫but a list of updates of whatever elements 103 00:05:24,900 --> 00:05:28,500 ‫are used in the host that's being used. 104 00:05:28,500 --> 00:05:30,660 ‫So the term virtual DOM, then, 105 00:05:30,660 --> 00:05:32,760 ‫also doesn't really make much sense 106 00:05:32,760 --> 00:05:35,010 ‫when we look at it from this angle, 107 00:05:35,010 --> 00:05:38,188 ‫which is just one more reason why the React team prefers 108 00:05:38,188 --> 00:05:42,450 ‫the more accurate name of React Elementary. 109 00:05:42,450 --> 00:05:44,880 ‫Now, all these details are of course 110 00:05:44,880 --> 00:05:46,740 ‫not really that important. 111 00:05:46,740 --> 00:05:49,350 ‫What I want you to retain from this slide 112 00:05:49,350 --> 00:05:52,680 ‫is that the React Library is not the one responsible 113 00:05:52,680 --> 00:05:54,206 ‫for writing to the DOM, 114 00:05:54,206 --> 00:05:57,213 ‫because the DOM is just one of many hosts 115 00:05:57,213 --> 00:06:00,330 ‫to which React apps can be committed, 116 00:06:00,330 --> 00:06:03,630 ‫so to which they can be output, basically. 117 00:06:03,630 --> 00:06:05,400 ‫And for each of these hosts 118 00:06:05,400 --> 00:06:08,340 ‫we have a different package that we can use. 119 00:06:08,340 --> 00:06:10,980 ‫And that's why in our index.js file, 120 00:06:10,980 --> 00:06:15,900 ‫we always import both React and React DOM, right? 121 00:06:15,900 --> 00:06:19,503 ‫And so now you know the exact reason why we have to do that. 122 00:06:21,840 --> 00:06:25,348 ‫All right, so after looking at all these phases 123 00:06:25,348 --> 00:06:29,250 ‫in so much detail, let's do a quick recap here 124 00:06:29,250 --> 00:06:32,880 ‫and summarize everything that we have learned. 125 00:06:32,880 --> 00:06:35,280 ‫So the whole process of rendering 126 00:06:35,280 --> 00:06:38,520 ‫and displaying a React application on the screen 127 00:06:38,520 --> 00:06:41,640 ‫starts with a trigger, which can either be 128 00:06:41,640 --> 00:06:45,270 ‫the initial render of the app or, a state update 129 00:06:45,270 --> 00:06:47,820 ‫in one of the component instances. 130 00:06:47,820 --> 00:06:50,220 ‫This then triggers the render phase 131 00:06:50,220 --> 00:06:53,880 ‫which does not produce any visual output. 132 00:06:53,880 --> 00:06:57,565 ‫So this phase starts by rendering all component instances 133 00:06:57,565 --> 00:06:59,910 ‫that need a re-render. 134 00:06:59,910 --> 00:07:02,250 ‫And rendering in React simply means 135 00:07:02,250 --> 00:07:04,770 ‫to call the components functions. 136 00:07:04,770 --> 00:07:08,250 ‫This will create one or more updated React elements 137 00:07:08,250 --> 00:07:11,195 ‫which will be placed in a new virtual DOM, 138 00:07:11,195 --> 00:07:15,303 ‫which is actually simply a tree of React elements. 139 00:07:16,140 --> 00:07:18,300 ‫Now, what's really important to remember 140 00:07:18,300 --> 00:07:21,270 ‫about this process is that rendering a component 141 00:07:21,270 --> 00:07:24,090 ‫will cause all of its child components 142 00:07:24,090 --> 00:07:25,890 ‫to be rendered as well, 143 00:07:25,890 --> 00:07:29,190 ‫no matter if props changed or not. 144 00:07:29,190 --> 00:07:31,410 ‫This is because React doesn't know 145 00:07:31,410 --> 00:07:33,420 ‫whether children have been affected 146 00:07:33,420 --> 00:07:36,540 ‫by the parent re-rendering or not. 147 00:07:36,540 --> 00:07:40,800 ‫Now, next up, this new virtual DOM needs to be reconciled 148 00:07:40,800 --> 00:07:42,750 ‫with the current fiber tree. 149 00:07:42,750 --> 00:07:45,510 ‫So with the representation of the elementary 150 00:07:45,510 --> 00:07:47,970 ‫before the state update. 151 00:07:47,970 --> 00:07:51,780 ‫This is necessary because it would be slow and inefficient 152 00:07:51,780 --> 00:07:55,200 ‫to destroy and rebuild the entire DOM tree 153 00:07:55,200 --> 00:07:59,160 ‫each time that something on the screen must be updated. 154 00:07:59,160 --> 00:08:03,720 ‫Instead, reconciliation tries to reuse as much of the DOM 155 00:08:03,720 --> 00:08:06,540 ‫as possible by finding the smallest number 156 00:08:06,540 --> 00:08:08,700 ‫of DOM updates that reflect 157 00:08:08,700 --> 00:08:11,313 ‫the latest state update on the screen. 158 00:08:12,360 --> 00:08:15,120 ‫Now this reconciliation process is done 159 00:08:15,120 --> 00:08:18,060 ‫using a reconciler called Fiber, 160 00:08:18,060 --> 00:08:20,820 ‫which works with immutable data structure 161 00:08:20,820 --> 00:08:23,130 ‫called the fiber tree. 162 00:08:23,130 --> 00:08:27,420 ‫And in this tree, for each React element and DOM element, 163 00:08:27,420 --> 00:08:30,312 ‫there is a fiber, and this fiber holds 164 00:08:30,312 --> 00:08:35,312 ‫the actual component state, props, and a queue of work. 165 00:08:35,910 --> 00:08:39,510 ‫After reconciliation, this queue of work will contain 166 00:08:39,510 --> 00:08:43,053 ‫the DOM updates that are needed for that element. 167 00:08:43,920 --> 00:08:47,400 ‫Now the computation of these DOM updates is performed 168 00:08:47,400 --> 00:08:51,120 ‫by a diffing algorithm, which step by step compares 169 00:08:51,120 --> 00:08:53,340 ‫the elements in the new virtual DOM 170 00:08:53,340 --> 00:08:56,070 ‫with the elements in the current fiber tree, 171 00:08:56,070 --> 00:08:59,100 ‫so to see what has changed. 172 00:08:59,100 --> 00:09:02,280 ‫So the final result of the render phase, 173 00:09:02,280 --> 00:09:06,112 ‫so basically of this reconciliation and diffing process, 174 00:09:06,112 --> 00:09:09,300 ‫is a second updated fiber tree 175 00:09:09,300 --> 00:09:13,860 ‫as well as a list of all necessary DOM updates. 176 00:09:13,860 --> 00:09:15,420 ‫Now, it's important to note 177 00:09:15,420 --> 00:09:18,600 ‫that the render face is asynchronous 178 00:09:18,600 --> 00:09:22,980 ‫so fiber can prioritize and split work into chunks 179 00:09:22,980 --> 00:09:26,280 ‫and pause and resume some work later. 180 00:09:26,280 --> 00:09:29,610 ‫And this is necessary for concurrent features 181 00:09:29,610 --> 00:09:33,390 ‫and also to prevent the JavaScript engine to be blocked 182 00:09:33,390 --> 00:09:35,493 ‫by complex render processes. 183 00:09:36,450 --> 00:09:40,230 ‫But anyway, the output of the render phase, 184 00:09:40,230 --> 00:09:45,030 ‫so the list of DOM updates, will finally actually be written 185 00:09:45,030 --> 00:09:47,880 ‫to the DOM in the commit phase. 186 00:09:47,880 --> 00:09:51,942 ‫So in this phase, a so-called renderer like React DOM 187 00:09:51,942 --> 00:09:56,310 ‫will insert, delete, and update DOM elements 188 00:09:56,310 --> 00:09:58,920 ‫so that we end up with an updated DOM 189 00:09:58,920 --> 00:10:02,550 ‫that reflects the new state of the application. 190 00:10:02,550 --> 00:10:04,410 ‫And unlike the render phase, 191 00:10:04,410 --> 00:10:07,440 ‫the commit phase is actually synchronous. 192 00:10:07,440 --> 00:10:11,010 ‫So all the DOM updates are performed in one go 193 00:10:11,010 --> 00:10:14,553 ‫in order to ensure a consistent UI over time. 194 00:10:15,600 --> 00:10:18,360 ‫Now finally, once the browser realizes 195 00:10:18,360 --> 00:10:22,710 ‫that the DOM has been updated, it starts a new browser paint 196 00:10:22,710 --> 00:10:24,480 ‫in order to visually update 197 00:10:24,480 --> 00:10:26,793 ‫the user interface on the screen. 198 00:10:27,750 --> 00:10:30,750 ‫Okay, and there you have it. 199 00:10:30,750 --> 00:10:32,610 ‫This is how, in a nutshell, 200 00:10:32,610 --> 00:10:36,240 ‫we go from updated React elements all the way 201 00:10:36,240 --> 00:10:41,190 ‫to an updated DOM and user interface on the screen. 202 00:10:41,190 --> 00:10:43,976 ‫So it sure was a really long process 203 00:10:43,976 --> 00:10:47,940 ‫but I hope that you have learned a lot along the way 204 00:10:47,940 --> 00:10:50,530 ‫and that it wasn't too overwhelming. 205 00:10:50,530 --> 00:10:54,450 ‫And again, keep in mind that you can build React apps 206 00:10:54,450 --> 00:10:58,718 ‫without being aware that most of these things even exist. 207 00:10:58,718 --> 00:11:03,300 ‫Now, some of these things do have practical implications 208 00:11:03,300 --> 00:11:06,060 ‫and also implications for performance 209 00:11:06,060 --> 00:11:09,060 ‫but we will talk about those later. 210 00:11:09,060 --> 00:11:11,040 ‫For now, just take a breath 211 00:11:11,040 --> 00:11:15,698 ‫as this was probably the hardest part of the entire course, 212 00:11:15,698 --> 00:11:19,140 ‫so good job of sticking with it to the end. 213 00:11:19,140 --> 00:11:20,820 ‫And let me know what you think 214 00:11:20,820 --> 00:11:23,673 ‫of the series of lectures in the Q and A.