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
Transcript
Intro
Hi, I'm Mark Erikson. 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.
What is “Rendering”?
[00:58] 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 ReactDOM and the web, but the same principles apply for any other React renderer like React Native or React Three Fiber.
When we write components, we have them return JSX tags, like
<
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 you rendered last time. And this process is called reconciliation.
Render and Commit Phases
[02:10] 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 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 executes all those changes synchronously in one sequence. It also then runs commit phase lifecycles like the useLayoutEffect hook or componentDidMount and DidUpdate in class components. Then after a short delay, it will run the useEffect hooks later. And this gives the browser a chance to paint in between the DOM updates and the useEffects running.
Queueing Renders
[03:24] Every React render pass starts with some form of setState 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 rerunning the top level ReactDOM.render method. Or there's also the new useSyncExternalStore hook which listens for updates from external libraries like Redux.
Now, prior to useSyncExternalStore, libraries like React-Redux still had to call setState in some form inside. Function components don't actually have a forceUpdate method, but you can do basically the same thing by creating a useReducer hook that just increments a counter every time.
Standard React Render Behavior
[04:20] 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. That queues a re-render, 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.
Now, 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 changed, it just recurses through the entire sub-tree.
“Rendering” vs “DOM Updates”
[05:53] 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.
Rules of React Rendering
[06:56] 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. And 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 Markbage of the React team wrote a gist where he talked about the rules of React. And we can summarize that as saying that render logic must not mutate existing data, do random math, make network requests, or queue up additional state updates. However, render logic can literally mutate objects created inside of this component during the render pass, 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.
Component Metadata and Fibers
[08:28] Another thing that I think a lot of people don't realize is that your component isn't actually the real source of truth. 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 be able to use React, but it can be helpful to know that this is how React is actually storing everything inside.
Component Types and Reconciliation
[09:38] 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 sub-tree 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.
Keys and Reconciliation
[11:17] 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. So if I have a to-do list, I would prefer to use todo.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.
Render Batching and Timing
[13:00] Every time we call setState, it's going to queue up another render pass. But React tries to be efficient with this. And if multiple components or 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 onClick. In React 18, React always batches multiple setStates into one render pass all the time.
So in this example, we have two setStates before an awake call and two setStates after an awake call. In React 17, the first two would be batched together, because they're synchronous, during the event handler. But since the awake causes a new event loop tick, in React 17, each of these other setStates would cause a separate render pass synchronously as soon as you make the call. In React 18, the first two setStates cause one render pass, and the other two setStates are batched together into a second render pass.
“Async Rendering” and Closures
[14:20] Another common source of confusion is the idea of what happens to my value after I call setState. And I 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 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 handleClick 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.
Render Behavior Edge Cases
[15:32] There are some edge cases with rendering. 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 sees the in-between appearance.
Reconcilers like ReactDOM 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 flushSync method that forces React to apply updates right away.
[16:31] Also, the thing that everybody dislikes is double rendering during StrictMode, 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’s rendered. Instead, put that in a useEffect 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.
Component Render Optimization Techniques
[17:21] 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 the same props and 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 sub-tree. 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 elements reference behavior is controlled by the parent component.
New Props References and Rendering
[18:49] 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.
Memoize Everything?
[19:36] So should you memoize everything? The short answer is no. The React team suggests don't do it by default, look for hot spots that are expensive and just memoize critical components to improve performance.
Immutability and Rerendering
[19:53] 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 re-render your component. Always, always do state updates immutably.
Measuring Component Rendering Performance
[20:16] 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 for 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.
Context and Rendering Behavior
[20:40] So how does context affect this? So context is really about dependency injection of a value into a sub-tree. And in order to update it, you have to call setState in a parent component, 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 context value.a and the application updated context value.b, it had to make a whole new object, and so the other component will render as well.
State Updates, Context, and Re-Renders
[21:22] 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 the component state normally. Which means that, by default, calling setState in a parent is going to make the entire application re-render regardless of whether context is involved or not. This is just default behavior.
Context Updates and Render Optimizations
[21:47] So how do we avoid this? There's a couple ways. Number one 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.
React-Redux Subscroptions
[22:16] 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 from how Context renders. Normally, the cost of running new selectors is less than the cost of React doing another render pass. So it's okay to have lots of useSelectors 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.
connect and useSelector Differences
[23:01] So connect wraps components, and it acts like React.useMemo. In fact, it actually has React.memo inside. useSelector is inside of a component, and it cannot stop it from rendering when the parent does. So if you've got function components and useSelector and you have large trees rendering, then wrap them in React.memo yourself.
Future React Improvements
[23:26] 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 possibility of drastically improving React app performance automatically. And then there has been discussion of adding a selectors option to useContext, which would allow you to only re-render if a certain piece of a 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.
React Advanced Conference 2023
