A Guide to React Rendering Behavior

Rate this content

React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering

25 min
24 Oct, 2022

AI Generated Video Summary

This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.

1. Introduction to React Rendering

Short description:

Hi, I'm Mark Eriksson, a senior front-end engineer at Replay.io. I'm here to share a brief guide to React rendering behavior.

Hi, I'm Mark Eriksson, and today I'd like to share with you a relatively brief guide to React rendering behavior. A few quick things about myself. I am a senior front-end engineer at Replay.io, where we are building a true time-traveling debugger for JavaScript. If you haven't seen it, please check it out. I will answer questions pretty much anywhere there is a text box on the Internet. I collect interesting links to anything that looks useful. I write extremely long blog posts, like the 8,500-word post this talk is based on, and I'm a Redux maintainer. But most folks really know me as that guy with the Simpsons avatar.

2. Understanding React Rendering

Short description:

Rendering is the process of React asking components to describe the UI based on current props and state. It then applies updates to the DOM. React collects a tree of objects that describe the component's appearance and compares it to the previous tree. The render phase loops over the component tree and forms the final tree. The commit phase applies DOM changes and runs lifecycle methods. React render passes start with set state calls. The default behavior is for parent components to recursively render their children.

So let's start by asking, what is rendering? Rendering is the process of React asking your components to describe what they want the UI to look like now, based on their current props and state. And then taking that and applying any necessary updates to the DOM.

Now I'm going to be talking in terms of React, DOM, and the web, but the same principles apply for any other React render, like React Native or React 3 Fiber. When we write components, we have them return JSX tags like angle brackets, my component. At compile time, those get converted into function calls to React.createElement, which in turn returns objects that have the type, props, and children. And these form a tree of objects that describe what the components should look like now.

React will call your components, collect this tree of objects, and then diff the current tree of elements against the last tree of elements that it rendered last time. And this process is called reconciliation. Each render pass can be divided into two different phases. The first phase is the render phase. And this is where React loops over the component tree, asks all of the components, what do you want the UI to look like now, and then collects all that to form the final tree.

Now the render phase can be split into multiple steps. And in fact, as of React 18, React might render a few components, pause, let the browser update, render a few more, maybe handle some incoming data like a key press action and a text input. And then once all of the components have been rendered, it moves on to the commit phase. During the commit phase, React has figured out which changes need to be applied to the DOM and it executes all of those changes synchronously in one sequence. It also then runs commit phase life cycles like the UseLayoutEffectHook or ComponentDidMount and DidUpdate in class components. Then after a short delay, it will run the UseEffectHooks later. And this gives the browser a chance to paint in between the DOM updates and the UseEffects running.

Every React render pass starts with some form of set state being called. For function components, it's the setters from the UseState hook and the dispatch method from UseReducer. For class components, it's this.setState or this.forceUpdate. You can also trigger renders by re-running the top-level ReactDom.Render method. Or there's also the new UseSyncExternalStore hook, which listens for updates from external libraries like Redux. Prior to UseSyncExternalStore, libraries like React Redux still had to call setState in some form inside. Function components don't actually have a force update method, but you can do basically the same thing by creating a UseReducer hook that just increments a counter every time.

Now it's very important to understand that the default behavior of React is that every time a parent component renders, React will recursively render all of the children inside this component. And I think this is where a lot of people get confused. So let's say we have a tree of four components, A, B, C, and D. And we call setState inside of the B component. React queues a re-render.

3. React's Rendering Process and Principles

Short description:

React starts rendering from the top of the component tree and continues down, even if components are not flagged for updates. Rendering does not always result in updates to the DOM. React compares the new and old elements to determine if any changes occurred. Rendering is necessary for React to determine if updates are needed. When writing components, rendering must be pure and not have side effects.

React starts at the top of the tree, looks at A and sees that it wasn't flagged for an update. It'll render B. B says my child should be C. And because B rendered, React continues on and renders the C component. C says I have a child. React keeps going. React renders D as well. So even though C and D weren't flagged for updates from calling setState, React kept on going and rendered all the components nested inside of B.

Something else that people get confused with is thinking that React renders components because props changed. No. By default it's just let's keep going all the way down the component tree. React does not care about whether or not props change. It just recurses through the entire subtree.

Now, it's also important to understand that rendering does not mean there are always updates for the DOM. Back when React first came out, the React team talked about the idea of rendering as being conceptually similar to redrawing the entire UI from scratch. But in practice, what happens is that a component might return the same kind of description that it did the last time. And so React will diff the new elements against the old elements and see that nothing actually changed. And so there are no actual updates needed to apply to this section of the DOM. But in order to figure that out, React had to go through the process of rendering and asking the component what it wants. So renders aren't actually a bad thing. This is how React knows if it needs to apply any updates to the DOM at all.

There are some rules that we need to follow when we're writing components that do rendering. And the biggest thing is that rendering must be pure and it cannot have any side effects. The typical definition of a side effect is anything that affects the world outside of this one component and this one render call. Now, not all side effects are obvious. And just because there is a side effect doesn't mean that the entire app is going to burn and explode. For example, if you mutate a prop, that's definitely a side effect, and that is bad, and that will cause problems, but technically speaking, a console.log statement is also a side effect. And having that in the component won't actually break things. Sebastian Markbaga of the React team wrote a guest where he talked about the rules of React and we can summarize that as saying that RenderLogic must not mutate existing data, do random math, make network requests, or cue up additional state updates. However, RenderLogic can literally mutate objects created inside of this component during the render pass.

4. React Rendering Details

Short description:

It's worth taking the time to read through the instructions. React stores component information in a data structure called a fiber. It loops over the fiber tree during rendering, comparing element types for efficiency. Avoid creating new component types inside another component. Keys are used to identify and track changes in lists.

It can throw errors if something goes wrong, and you can lazy-initialize some values. So it's worth taking the time to read through those instructions.

Another thing that I think a lot of people don't realize is that your component isn't React actually stores information about the component tree internally in a data structure called a fiber. And fibers are just plain JavaScript objects that describe one component instance in the tree. They hold a reference to the type of the component, they have pointers to parent and sibling and child components. They store current and incoming props and state, and information about whether this component needs something like context. These are the real data for each component.

So during the rendering pass, React is actually looping over this tree of fiber objects. It's reading the props out of there, passing those into components, reading the previous state, applying queued state updates, and updating the tracking info on the way through. Now, you don't need to look at these values to understand to be able to use React, but it can be helpful to know that this is how React is actually storing everything inside.

We said earlier that React diffs the old and new element trees to figure out what changed. And that process can be very expensive. React will try to reuse as much of the existing component tree and DOM nodes as possible. But it also takes some shortcuts to speed up this process. And the biggest one is that it compares the current and the new element types at each given spot in the tree. And if the element type has changed to a new reference, it assumes that the entire existing subtree of components would probably be completely different, and it will unmount all the components at that tree, which means removing all the DOM nodes at that location in the tree. And then it recreates all that from scratch.

So a common mistake that I see is when people try creating new component types inside of another component while it's rendering. And this is bad because every time parent component renders, child component will be a new reference. And that means it will always fail the comparison. And every time parent component renders, React will destroy the old child component, unmount all the DOM nodes inside of there, and have to recreate them. So never, ever create component types inside of a component. Always create them separately at the top level.

Another thing that affects reconciliation is keys. Now we pass in what looks like a prop named key as an identifier, but it's not actually a real prop. It's actually an instruction to React that here's how you tell these different things apart. And in fact, React always strips key out of the props. So you can never have props.key inside of a component, it'll always be undefined. Now most of the time we use keys when we're rendering lists, because if the list is going to change at all, React needs to know which items got added, updated or removed. Ideally, keys should be unique IDs from your data.

5. React Rendering Tips

Short description:

If you have a to-do list, use the to-do ID as the keys. Never use random values for keys. Apply a key to a React component to destroy and recreate it intentionally. React batches multiple set states into one render pass. After calling setState, the updated value is not immediately available due to async rendering and closure.

So if I have a to do list, I would prefer to use to do.id as my keys. You can use array indices as a fallback if the data isn't going to change over time. And never, ever use random values for keys.

Now it's also worth noting that you can apply a key to any React component at any time. And there are times when you might want to use this to tell React, hey, I had this component here, but I actually intentionally want you to destroy it and recreate it when something changes. And a good example of this would be maybe I have a form that is being initialized by props. It has its own state inside. And if the user selects a different item, I want it to recreate the form from scratch so that everything gets initialized properly.

Every time we call set state, it's going to queue up another render pass. But React tries to be efficient with this. And if multiple render passes are queued up in the same event loop tick, React will actually batch them together into one render pass. Now, in React 17, this only happened automatically inside of event handlers like on click. In React 18, React always batches multiple set states into one render pass all the time. So in this example, we have two set states before an await call, and two set states after an await call. In React 17, the first two would be batched together because they're synchronous during the event handler. But since the await causes a new event loop tick, in React 17, each of these other set states would cause a separate render pass synchronously as soon as you make the call. In React 18, the first two set states cause one render pass and the other two set states are batched together into a second render pass.

Another common source of confusion is the idea of what happens to my value after I call setState. And I really see this happen all the time. People try to call setState with a new value, and then they try to log the state variable thinking it's going to have already been updated. And this doesn't work for a couple of reasons. The usual short answer is that we say, well, React rendering is async. And that's technically sort of true. Technically speaking, it will be synchronous. But at the end of the event loop, so from the point of view of this code, it's async because it's not going to happen right away. But the real problem here is that the event handler is a closure. It can only see values like counter at the time this component last rendered. The next time this component renders, there's a new copy of the handle click function, and it will see the new copy of counter next time. So trying to use this value right after you call setState is almost always the wrong idea. There are some edge cases with rendering.

6. React Rendering: Batching and Double Rendering

Short description:

If you call setState in useLayoutEffect or ComponentDidMount or DidUpdate, it will run synchronously. This allows you to grab DOM nodes, measure their size, and render again based on that information. React DOM and React Native have methods to alter batching behavior. In React 17 and earlier, calls can be wrapped in batched updates. In React 18, there's a flush-sync method to force immediate updates. Double rendering in strict mode catches bugs. Function components can call setState conditionally, similar to getDerivedStateFromProps in class components.

One is that if you call setState in useLayoutEffect or ComponentDidMount or DidUpdate, it will run synchronously. And the main reason for this is that you might do a first render, and then you want to grab the DOM nodes, measure their size, and render again based on that information. And so by doing the render synchronously, React updates the DOM before the browser has a chance to paint, and the user never saw the in-between appearance.

Reconcilers like React DOM and React Native do have a couple methods that can alter this batching behavior. In React 17 and earlier, we might wrap calls in batched updates to force batching outside of event handlers. In React 18, we do the opposite. Because batching is the default, there's a flush-sync method that forces React to apply updates right away. Also, the thing that everybody dislikes is double rendering during strict mode, and React does this to try to catch bugs. This does mean that you can't use console.log in the middle of a function component to count the number of times that it rendered. Instead, put that in a use effect or use the React DevTools to measure. And finally, there is one case where function components can call setState while rendering, and that's if they do it conditionally. And if you do that, React will see that you called setState and immediately run the component again with the new state. This is the equivalent of the getDerivedStateFromProps behavior in class components.

7. Optimizing React Rendering and Context

Short description:

To optimize rendering, skip unnecessary renders by using react.memo or returning the same element reference object. Memoize critical components, update state immutably, and use the React DevTools profiler for performance measurement. Context in React causes all consuming components to re-render when updated.

So how do we make this stuff go faster? We could say that a render is wasted if it returned the exact same output as last time, and because render output should be based on props and state, if the component has same props in same state, it's probably returning the same output. So we can optimize behavior by skipping the render if the props haven't changed. And this will also skip the entire subtree. The normal way to do this is wrap your component with react.memo, which automatically checks to see if any one of the props have changed. In class components, you could use ShouldComponentUpdate or PureComponent, or actually also wrap it with react.memo. There's one other way to do this, and this is having the parent component return the same exact element reference object as it did last time. And if you do that, React will skip rendering this component and all its child. So you could use the UseMemo hook to save a React element for later, or you can also use props.children. And the difference between this and React.memo is that React.memo is effectively controlled by the child component, because we've wrapped it. But the same element's reference behavior is controlled by the parent component.

So we said earlier that it's not true that React renders child components when props change. React always renders all components by default. The only time prop references matter is if the component is already optimized using React.memo. Now note that if you're passing in new children like this, you are passing in a new props.children reference every time, and React.memo will never actually save you any work. If you do need to pass consistent references to a child, then call useCallback or useMemo. And finally, don't wrap host components like Button in React.memo. It doesn't actually save you anything.

So should you memoize everything? The short answer is no. The React team suggests don't do it by default. Look for hotspots that are expensive and just memoize critical components to improve performance. Also, state updates should always be done immutably. If you mutate data, then number one, it's likely to cause bugs. Number two, React might actually think nothing has actually changed and not actually rerender your component. Always, always do state updates immutably. If you need to measure performance, the React DevTools has a profiler tab, and you can record yourself using the app for a couple minutes and then look in the profiler to see which components rendered and how long. You can do it in Dev mode to get a sense of the relative timings, and there's also a special profiling build of React to see more of what the times would be like in production. So how does context affect this? So context is really about dependency injection of a value into a subtree. And in order to update it, you have to call SetStateInApparentComponent, and passing in a new value causes all the components that consume the context to re-render. Right now, there's no way to have a component read only part of a context value. If you read contextValue.a and the application updated contextValue.b, it had to make a whole new object, and so the other component will render as well.

8. Optimizing React Rendering and Redux

Short description:

Updating state queues a render. React recursively renders by default. Ways to avoid unnecessary re-renders include using React.memo or props.children. React Redux passes down the Redux store from context, and each component subscribes separately. Running new selectors is less costly than React doing another render pass. Connect wraps components and acts like React.memo. The React team is working on a new compiler called React forget to improve performance. There has been discussion of adding a selectors option to use context.

So we know that updating state queues a render. React recursively renders by default, you give a new value to a context provider, and those come from component state normally, which means that by default, calling SetStateInApparent is going to make the entire application re-render, regardless of whether context is involved or not. This is just default behavior.

So how do we avoid this? There's a couple ways. Number 1 is put the first child of the context provider inside of React.memo. The other option is to use props.children, in which case, the same element optimization comes into play. Now, when a component reads the value from context, it's going to render, and all of the nested children are going to re-render from there. Again, normal behavior.

So how does React Redux work? Well, React Redux passes down the Redux store from context, and then each component subscribes to the Redux store separately. And every time an action is dispatched, it reads the state, pulls a value from the selector, and compares to see if that changed. That's very different than how context renders. Normally, the cost of running new selectors is less than the cost of React doing another render pass. So it's OK to have lots of use selectors and lots of components connected, but the selectors do need to be very fast. And that's one of the reasons why we have the reselect library for memoization.

So connect wraps components, and it kind of acts like React dot use memo. In fact, it actually has React dot memo inside. Use selector is inside of a component and it cannot stop it from rendering when the parent does. So if you've got function components and use selector and you have large trees rendering, then wrap them in React dot memo yourself. There are some more improvements on the way. The React team is working on a new compiler called React forget, which will automatically memoize not just your hook dependency arrays, but also optimize element output using the same memoization approach. This has a real impossibility of drastically improving React app performance automatically. And then there has been discussion of adding a selectors option to use context, which would allow you to only re-render if a certain piece of the context value changes. So both of these are things to keep an eye on. After this talk is up, I'll have the slides up on my blog and I'll have links to some further resources and information. Hopefully this gives you a better idea of how React works so that you're able to use it more efficiently. Thanks and have fun using React.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn