‫Welcome to the last lecture
‫of this section.
‫And it was a long
‫and complicated section, I know.
‫But hopefully, you enjoyed learning
‫about all these internal workings of React
‫as much as I did.
‫And now, to finish,
‫I thought it was a great idea
‫to summarize the key learnings
‫that you should retain from this section.
‫Now, this is not a summary
‫of everything that we learned
‫but only the practical takeaways and conclusions
‫that you will actually need
‫to know in practice
‫as you build your own React apps
‫and this is necessary
‫because I've mentioned multiple times
‫that you actually don't need
‫to know all this complicated stuff
‫about how React works behind the scenes
‫but you do need to know
‫the practical implications of it.
‫And so in this lecture is where I gathered
‫all those practical implications
‫in the form of text slides that you can save
‫and read in the future.
‫But anyway, let's now move on
‫to our first point,
‫which is that a component is basically
‫like a blueprint for a piece of UI
‫that will eventually exist on the screen.
‫When we then use a component,
‫React creates a component instance,
‫which is like an actual physical manifestation
‫of a component, which contains props,
‫state, effects, and more.
‫So following the analogy of the blueprint,
‫the component is like a blueprint for a house
‫and the component instances
‫are like the actual houses
‫that have been built from that blueprint.
‫Finally, a component instance when rendered,
‫will return a React element.
‫Okay, so let's now move on to rendering.
‫So in React, rendering only means
‫calling component functions
‫and calculating what dumb elements need
‫to be inserted, deleted, or updated later.
‫So rendering has nothing to do
‫with actually writing.
‫So with actually updating the DOM.
‫Writing to the DOM is actually called
‫committing in the React language.
‫So what I want you to remember here
‫is that each time a component instance
‫is rendered and re-rendered,
‫the function is simply called again.
‫But what actually triggers a render to happen?
‫Well, as you should probably know already,
‫only the initial app render
‫and state updates can cause a render
‫which will happen for the entire application.
‫So even though it might look
‫as if only one single component is rendered,
‫the process is actually executed for all components.
‫Now, when a component instance
‫does get re-rendered, all its children
‫will get re-rendered as well.
‫Now, this doesn't mean that all children
‫will get updated in the DOM
‫because thanks to reconciliation,
‫React will check which elements
‫have actually changed between the two renders.
‫Now, one of the main parts of this reconciliation
‫that I just mentioned is diffing.
‫So diffing is how React decides
‫which dumb elements need to be added
‫or modified later.
‫Now, if between two renders,
‫a certain React element stays
‫at the same position in the elementary,
‫the corresponding DOM element
‫and the component state
‫will simply stay the same.
‫So the DOM will not be modified in this case
‫which is a huge win for performance.
‫However, if the element did change
‫to a different position in the tree
‫or if it changed
‫to a different element type altogether,
‫then the DOM element
‫and the corresponding state will be destroyed.
‫So they will basically be reset.
‫Now, one cool thing about the diffing algorithm
‫is the fact that we can actually influence it
‫by giving elements a key prop,
‫which then allows React to distinguish
‫between multiple component instances
‫of the same component type.
‫So when the key on a certain element
‫stays the same across renders,
‫the element is kept in the DOM
‫even if it appears
‫at a different position in the tree.
‫And so this is the reason why
‫we need to use keys in lists
‫because it will prevent unnecessary recreations
‫of elements in the DOM.
‫Now, on the other hand,
‫when we change the key between renders,
‫the DOM element will be destroyed and rebuilt.
‫And so this is a very nice trick
‫that we can use in order to reset state,
‫which is sometimes necessary as we saw
‫in two practical examples in this section.
‫Next, we have one very important rule
‫that you must never ever forget
‫which is that you should never declare
‫a new component inside another component.
‫That's because doing so will recreate
‫that nested component every time
‫the parent component re-renders
‫so that nested component
‫would always be a new variable basically.
‫And so this means that React
‫would always see the nested component
‫as a brand new component,
‫and therefore reset its state each time
‫that the parent's state is updated.
‫Now, the reason why this happens
‫is not the important part,
‫but what matters is that
‫you should always, always declare.
‫So you should write new components
‫at the top level of a file,
‫never inside another component.
‫Now, the logic that is responsible
‫for creating DOM elements
‫so basically logic that produces JSX
‫is called render logic
‫and this render logic is not allowed
‫to produce any side effects.
‫So render logic can have no API calls,
‫no timers, no object or variable mutations,
‫and no state updates.
‫The only place where side effects are allowed
‫is inside event handlers and inside useEffect.
‫Okay, now, after all this rendering,
‫it's time to finally update the DOM,
‫which happens in the commit phase.
‫However, it's actually not React
‫that does this committing
‫but a so-called renderer called ReactDOM.
‫That's why we always need
‫to include both these libraries
‫in a React web application project.
‫We can also use other renderers
‫to use React on different platforms.
‫For example, to build mobile
‫or native applications with React native.
‫All right, and now,
‫for the rest of this last slide,
‫let's leave the topics related to rendering behind
‫and quickly talk about state and events.
‫So when we have multiple state updates
‫inside an event handler function,
‫all these state updates will be batched.
‫So basically, they will happen all at once
‫and this is super important because it means
‫that multiple related state updates
‫will only create one re-render which,
‫once again, is great for performance.
‫And since React 18, automatic batching
‫even happens inside timeouts,
‫promises, and native event handlers.
‫Now, one super important practical implication of this
‫is that we cannot access a state variable
‫immediately after we update it
‫which is why we say
‫that state updates are asynchronous.
‫Next up, when we use events
‫inside event handler functions,
‫we get access to a so-called synthetic event object,
‫not the browser's native object.
‫So the React team created synthetic events
‫so that events work the exact same way
‫across all browsers
‫and the main difference between synthetic
‫and native events is that
‫most synthetic events do actually bubble
‫and that includes the focus, blur,
‫and change events, which do usually not bubble
‫as native browser events.
‫The only exception here is the scroll event.
‫Okay, and now, finally,
‫let's remember that React is a library
‫and not a framework.
‫This means that you can basically assemble
‫your applications using your favorite
‫or the community's favorite third-party libraries
‫and this is great for flexibility
‫and creative freedom.
‫The downside of this freedom is that
‫there is an basically infinite amount
‫of libraries that you can choose from.
‫And so you need to first find and then learn
‫all these additional libraries that you need.
‫However, that's not that big of a problem
‫because you will learn
‫about the most commonly used libraries
‫in the main projects of this course.
‫All right, and there you have it.
‫So this is essentially what I need you to remember
‫from this section going forward.
‫And again, I hope that you found this section
‫as interesting as I did.
‫But no matter if you did or not,
‫please leave your comments about it
‫in the Q and A section.
‫And now, maybe take some time
‫to basically recover from all this new material
‫and all these new concepts that you learned.
‫And then once you're done,
‫I'll see you in the next section.