A 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.

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.

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.

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.

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.

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.

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.

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.