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
A Guide to React Rendering Behavior
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
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.
2. Understanding React Rendering
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
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
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.
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
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
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
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
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.