How Rendering Works: Overview | Lecture 123 | React.JS 🔥
Summary
TLDRThis video script provides an insightful overview of how React renders applications behind the scenes. It delves into the three phases involved in displaying components on the screen: the render phase, where React calls component functions and figures out how to update the DOM; the commit phase, where React actually updates the DOM; and the browser repaint phase, where visual changes are displayed. The script clarifies the distinction between React's definition of 'rendering' and the traditional understanding, emphasizing that rendering in React is an internal process without visual changes. It also explores how renders are triggered and the importance of understanding the entire rendering process for a comprehensive grasp of React's inner workings.
Takeaways
- 🧩 React applications are built with components, which can be nested and instantiated multiple times.
- 📄 JSX code in components produces React.createElement calls, which create React elements representing the UI.
- 🌉 React elements are eventually transformed into DOM elements and rendered on the screen.
- 🔄 React's rendering process is triggered by state updates or the initial application load.
- 📖 The rendering process has three phases: render, commit, and browser repaint.
- 🎨 In the render phase, React calls component functions to determine how to update the DOM, but doesn't actually update it.
- ✏️ In the commit phase, React updates the DOM to reflect the latest state changes.
- 💻 The browser then repaints the screen to display the visual changes.
- ⏱️ Renders are not triggered immediately after state updates, but are scheduled when the JavaScript engine has free time.
- 🔀 In some cases, like multiple setState calls in the same function, renders are batched together.
Q & A
What is the main purpose of this lecture series?
-This lecture series aims to provide an in-depth understanding of how React renders applications behind the scenes. It is divided into three parts, with this video serving as an overview and the next two videos going into the React internals in greater detail.
What is the difference between a component and a component instance in React?
-A component is a reusable piece of code that defines the structure and behavior of a part of the user interface. A component instance is the actual physical representation of a component in the application, holding its own state and props.
What role do React elements play in the rendering process?
-React elements are the output of the JSX code, produced by calling the React.createElement function for each component instance. These React elements are then transformed into DOM elements and displayed as the user interface on the screen.
What is the purpose of the render phase in React?
-In the render phase, React calls the component functions and figures out how to update the DOM to reflect the latest state changes. However, it does not actually update the DOM during this phase.
How does React's definition of rendering differ from the traditional understanding?
-In React, rendering refers to the internal process of calling component functions and determining DOM updates, not the actual updating of the DOM or displaying elements on the screen. This differs from the traditional understanding of rendering as displaying elements visually.
When does the actual DOM update happen in React?
-The actual DOM update happens in the commit phase, after the render phase. During the commit phase, new elements may be added to the DOM, existing elements may be updated, or elements may be removed to reflect the current state of the application.
What are the two ways in which a render can be triggered in React?
-A render can be triggered in React in two ways: the initial render when the application first runs, and a re-render triggered by a state update in one or more component instances.
Does React trigger a render immediately after a state update?
-No, React does not trigger a render immediately after a state update. Instead, the render is scheduled to occur when the JavaScript engine has some free time, usually just a few milliseconds later.
What is the significance of batching renders in React?
-In some situations, such as multiple setState calls in the same function, React will batch renders together. This means that instead of triggering a render for each state update, React will combine them into a single render, improving performance.
What is the key takeaway from this lecture?
-The key takeaway from this lecture is that the rendering process in React is more complex than it initially appears. It involves multiple phases, including the render phase, where component functions are called and DOM updates are determined, and the commit phase, where the actual DOM updates occur.
Outlines
🎬 React Rendering Process Overview
This paragraph serves as an overview of the React rendering process, which is split into three parts across this and the next two videos. It explains that as we build applications, we create components that produce React elements, which are ultimately transformed into DOM elements and displayed on the screen. While we understand how components are transformed into React elements, we don't yet understand how these React elements end up in the DOM and displayed on the screen, which is the focus of this series.
⚡️ Triggering a Render in React
This paragraph discusses how a render is triggered in React. There are two ways: 1) The initial render when the application first runs, and 2) A re-render triggered by a state update in one or more component instances. It's important to note that the render process is triggered for the entire application, not just the updated component. Renders are not triggered immediately after a state update, but rather scheduled when the JavaScript engine has free time. In some cases, like multiple setState calls in the same function, renders can be batched together.
Mindmap
Keywords
💡React
💡Components
💡JSX
💡React Elements
💡Rendering
💡Render Phase
💡Commit Phase
💡State
💡Initial Render
💡Re-render
Highlights
We are now ready to finally learn about how exactly React renders our applications behind the scenes.
As we build our applications, what we're really doing is building a bunch of components.
We then use these components inside other components, as many times as we want, which will cause React to create one or more component instances of each component.
As React calls each component instance, each JSX will produce a bunch of React.createElement function calls, which in turn will produce a React element for each component instance.
This React element will ultimately be transformed to DOM elements and displayed as a user interface on the screen.
We don't understand yet how these React elements actually end up in the DOM and displayed on the screen.
This process is started by React each time that a new render is triggered, most of the time by updating state somewhere in the application.
In the render phase, React calls our component functions and figures out how it should update the DOM to reflect the latest state changes, but it does not actually update the DOM in this phase.
React's definition of render is very different from what we usually think of as a render, which can be quite confusing.
In React, rendering is not about updating the DOM or displaying elements on the screen. Rendering only happens internally inside of React, and so it does not produce any visual changes.
Once React knows how to update a DOM, it does so in the commit phase, where new elements might be placed in the DOM, and already existing elements might get updated or deleted to reflect the current state of the application.
It's really this commit phase that is responsible for what we traditionally call rendering, not the render phase.
Finally, the browser will notice that the DOM has been updated and repaint the screen, which is the final step that actually produces the visual change that users see on their screens.
A render can be triggered by the very first time the application runs (initial render) or a state update happening in one or more component instances (re-render).
The render process is triggered for the entire application, not just for one single component, although that doesn't mean the entire DOM is updated.
Transcripts
We are now ready
to finally learn about how exactly React renders
our applications behind the scenes.
Now there is so much to learn here
that I split up this lecture into three parts.
So it's this video and the next two ones.
This one serves more as an overview
and then in the next two videos,
we're gonna go really deep
into some React internals.
And let's start with just a small recap
so that we're all on the same page.
So as we build our applications,
what we're really doing
is building a bunch of components.
We then use these components inside other components
as many times as we want
which will cause React to create one
or more component instances of each component.
So these are basically
the actual physical components
that live in our application
and holds state and props.
Now, as React calls each component instance,
each JSX will produce a bunch
of React dot create element function calls
which in turn will produce a React element
for each component instance.
And so this React element
will ultimately be transformed
to DOM elements and displayed
as a user interface on the screen.
So we have a pretty good understanding
of the initial part of this process,
so of transforming components to React elements.
However, what we don't understand yet
is the second part of the process,
so how these React elements actually end up
in the DOM and displayed on the screen.
Well, luckily for us,
that is exactly what this series
of lectures is all about.
So in this lecture,
we're gonna have a quick overview
of each of the phases involved in displaying
our components onto the screen.
Then we're gonna zoom into each of these phases
to learn how the entire process
works internally behind the scenes.
So this process that we're about to study
is started by React each time
that a new render is triggered,
most of the time by updating state
somewhere in the application.
So state changes trigger renders
and so it makes sense
that the next phase is the render phase.
In this phase, React calls our component functions
and figures out how it should update the DOM,
so in order to reflect
the latest state changes.
However, it does actually not update
the DOM in this phase.
And so Reacts definition of render
is very different from what
we usually think of as a render,
which can be quite confusing.
So again, in React, rendering is not
about updating the DOM
or displaying elements on the screen.
Rendering only happens internally inside of React
and so it does not produce any visual changes.
Now, in all the previous sections,
I have always used the term rendering
with the meaning of displaying elements on the screen
because that was just easy to understand
and it just made sense, right?
However, as we just learned,
the rendering that I used to mean
is really this render plus the next phase.
And speaking of that next phase,
once React knows how to update a DOM,
it does so in the commit phase.
So in this phase,
new elements might be placed in the DOM
and already existing elements might get updated
or deleted in order to correctly reflect
the current state of the application.
So it's really this commit phase that is responsible
for what we traditionally call rendering,
not the render phase, okay?
Then finally, the browser will notice
that the DOM has been updated
and so it repaints the screen.
Now this has nothing to do with React anymore
but it's still worth mentioning
that it's this final step that actually produces
the visual change that users see on their screens.
All right, so let's now zoom
into each of these different steps,
starting with the triggering of a render.
So there are only two ways
in which a render can be triggered.
The first one is
the very first time the application runs
which is what we call the initial render.
And the second one is a state update happening
in one or more component instances
somewhere in the application
which is what we call a re-render.
And it's important to note
that the render process really is triggered
for the entire application,
not just for one single component.
Now that doesn't mean
that the entire DOM is updated
because remember, in React,
rendering is only about calling the component functions
and figuring out what needs to change in the DOM later.
Now again, this might seem confusing now
because earlier in the course,
I made it seem as though React
only re-renders the component
where the state update happened.
But that's because we were learning
how React works in practice.
And in fact, when we look at what happens in practice,
it looks as if only
the updated component is re-rendered.
But now we are learning
how React actually works behind the scenes.
And so now we know that React looks
at the entire tree whenever a render happens.
Finally, I just want to mention
that a render is actually not triggered immediately
after a state update happens.
Instead, it's scheduled for when
the JavaScript engine basically
has some free time on its hands.
But this difference is usually
just a few milliseconds
that we won't notice.
There are also some situations
like multiple sets state calls
in the same function where renders will be batched
as we will explore a bit later.
So this is how renders are triggered
which is the easy part.
What follows is the hard part,
which is the actual rendering.
And so let's learn all about that in the next video.
Browse More Related Video
How Rendering Works: The Render Phase | Lecture 124 | React.JS 🔥
Components, Instances, and Elements | Lecture 121 | React.JS 🔥
Instances and Elements in Practice | Lecture 122 | React.JS 🔥
Performance Optimization and Wasted Renders | Lecture 239 | React.JS 🔥
How Events Work in React | Lecture 134 | React.JS 🔥
React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM)
5.0 / 5 (0 votes)