The Art of Ignoring Best Practices for React Performance

Have you ever wanted to be a React bad boy? I know you've all been good engineers following all the best practices, but where has that gotten you? Into complex React projects with slow components? Then you find yourself wanting to smash your mechanical keyboard, wondering why you need to use unidirectional data flow to avoid calling React hooks conditionally, to store state using React's useState hook. You hear a little voice whispering, you can be a React troublemaker. You can break all of these rules. You think jaywalking, littering, and riding a motorcycle is bad. Wait until you conditionally call React hooks, build impure components, and even pull in a second UI library?

My name is tigerhooks. You can find me at notwoods and all the socials. I'm a senior software engineer working at Microsoft and I previously helped build three web browsers, Edge, Chrome, and Firefox. I've worked with React for over eight years, and I am going to show you the art of ignoring best practices. Any documentation you read comes with a hidden asterisk. It covers most cases, but we all have different setups and environments. This talk will show you the edge cases that you know when to follow and when not to follow best practices and how to get yourself on Santa's Nautilus this Christmas. Since we're in dangerous territory, use what I'm about to show you with caution. Some of these tricks can make your code hard to follow. Use your best judgment, evaluate tradeoffs, and communicate what you're trying to do. Here is what I'll show you today. We'll talk about when does React decide to rerender, then how to isolate expensive hooks and state changes using impure components, and how to only update leaf components by using a different UI library.

Let's start with the first topic. When does React rerender? Well, React starts with a simple rule. Every rerender starts with a state change. You might be thinking, wait, don't components rerender when their props change? When context changes? But no, the trick is that whenever a component rerenders, it also rerenders every descendant component. React uses rerenders to figure out what needs to change to keep your UI in sync with state. Your component will return a mix of other components and HTML elements. When another component is encountered, React will then proceed to render it, and that component will return another mix of components and HTML elements. Eventually, React will just be left with an HTML tree. Now that it's finished rerendering components, it will begin the process of virtual DOM diffing. React will compare the new HTML against the previously rendered HTML, and then update the nodes that have changed in the DOM. But React does not think too hard about what components to render. You might think that only components that read the state will update, but actually everything rerenders. It doesn't matter if the state is passed in as a prop, or if the component takes no props at all. Whenever this increment button is clicked, and the counter state is updated, the MyCounter component and all its descendants will re-render as indicated by these green flashes.

Even though the title component doesn't read the count state, it also re-renders. The only exception to this is React.Memo. Memo places an extra layer around a component, which tells React, if my props are the same, I pinky promise that I would return the exact same result. You can just remember what I returned last time. No need to render me again. Now whenever this increment button is clicked, and the counter state is updated, MyCounter will re-render, and then it will attempt to re-render its descendants. Title doesn't read the count state, so its props have not changed. As a result, it doesn't re-render, thanks to React.Memo. MyCounter display is still re-rendered, as this count prop is changing. Now Memo is a little bit weird with React.Context. Context acts like a second set of invisible props, past every component. So if your component is using React.Memo, the props and context it's reading must be exactly the same, or else the component will be caused to re-render. If you want to see whenever a component re-renders in your own code, React DevTools can help out. After opening your browser's developer tools, you can go to React's Profiler tab, click on the gear icon to open the extension settings, and then turn on a setting labeled, Highlight Updates When Components Re-render. This will cause green rectangles to flash around each re-rendered component in your UI. And if you're trying to track down what's causing a re-render in your code, you can turn on a different setting labeled, Record Why Each Component Rendered While Profiling. You can find it under the Profiler tab in React's DevTools settings dialog. Then, when you save a recording using React's Profiler, each render will be captured and you can see what triggered it. If you want to learn more, you can check out Josh Komu's excellent article with live samples you can play with.

Now, React does recommend that instead of caring about how frequently you're re-rendering, you just simply write your components that render quickly. You know, sure, just have you and your entire team always write perfectly performing code. What could go wrong? But when, inevitably, you do end up with expensive components, we can trick React to re-render less often. That's when we start breaking the rules and ignoring best practices.

Now that we know that every re-render in React is triggered by a state's change, let's figure out how to avoid these state changes. For our second topic, we'll discuss an approach to avoid state changes by isolating expensive hooks. Now, what happens if we have hooks that fetch some data and then place it in state? After the effect runs, React will update. Let's start with an example hook called useGetData. It fetches some state value and they will call setState which triggers a re-render. But what happens if that first piece of state is used to fetch more data? For example, we might use an ID from the previous fetch to then start another fetch effect. After each effect runs, React will re-render again. That can be a lot of re-renders, even though we're not even using these in-between state values. If we only use the last piece of state in our UI, all those other re-renders were wasted work. Since each state update will cost the component and all of its descendants to render, that can result in a lot of components rendering unnecessarily.

How can we isolate this? Well, ideally, a chain like this should be refactored. Rather than using state to trigger effects, you can instead set up a promise chain inside a single effect. But that also requires time to be invested in code cleanup and taken away from future work. Instead, we can isolate the state changes into a single leaf node so that the rest of the tree doesn't need to update until the final value is ready. We'll write a specialized React component that just runs side effects and doesn't return any children, so it'll be cheaper to render. Here, we've made a component called ExpensiveEffect that is simply in charge of calling the useGetData hook. It will always return null. The final result from the hook will then be passed back up to the parent using props.setState, which will update the parent state. Now, all state changes in the expensive hook are isolated by this effect component. This does break unidirectional data flow. Instead, there's a small little loop-de-loop where we pass input into and then get output from the effect component. Now, data is getting fetched in ExpensiveEffect and then passed up to app, which is passed back down to UI. It's a quick refactor that can improve performance a lot by detaching state from child components in the tree. In Microsoft Loop, we had a component high in our tree that rendered five times due to intermediate state used in a hook. Wrapping that single hook in an effect component made this startup path five times faster. Any expensive components that have a lot of unnecessary state can benefit greatly from using effect components.

This pattern also introduces an additional superpower. We can use all the flexibility we have when deciding when to render components unlike hooks. Want to conditionally call your hook? Well, you can just conditionally render the effect components. Need to lazy load your hook? Wrap the effect component with React.lazy and suspense. This effect suffix is a convention used to indicate this component doesn't render anything and it will just be fetching data.

This pattern is adopted from Android's Jetpack Compose, which is a library that has a very similar functionality to React. In Jetpack Compose, there is no difference between hooks and components. They are all composables. Composables that return data are camel case, like load data and mutable state of. Composables that show UI are Pascal case, like React, like app. And composables that just run some side effect are Pascal case but with an effect suffix.

By wrapping your state changes into a child component, we can prevent them from affecting the rest of the React tree. The effect component has no children of its own to re-render and it can't make sibling components render. We successfully isolated all of our state changes.

Now for our third topic, we'll discuss how to reduce the number of components in a tree that render. If our state is very high up, the entire app is going to re-render. Effect components does let us reduce how often this happens, but it does still need to happen at some point.

Now what if you have a large list or a piece of data is only used by maybe a time stamp in some list items? Do we really need to re-render the entire list just to update a few strings? We could use context to pass a value down from the grandparent to his grandchild, but re-renders still need to happen because we're using React.useState.

But what if we use state without useState? We would need to do what React does for us, store a piece of state, have a way to set that state, and also inform everyone who cares that the state changed. Well, React does do this pretty well, but other libraries can do it too. So let's just go ahead and start using a whole second competing UI library, Svelte.

The trick is, we're not actually using Svelte for his UI code. Instead, we'll unwrap the package and just use a special store API. Svelte stores act like a portable use state. They have a set method to update the state and components watching the store. You can even pass in a callback to update state based on the previous state value, just like React. The store API is independent of the rest of Svelte, so we don't need to worry about pulling in anything else. You can use eslint to disable direct Svelte imports in your code, and it only allows importing from Svelte slash store.

Now instead of passing around a raw state value, we can pass around a Svelte store instead. You can do so using props or context, like regular values. The store does not change identity, so changing values will not affect React.memo. Now, at some point, we do still need to convert from the Svelte store back into React.state. Instead of placing the hook inside the ancestor branch component, we can place multiple hooks inside each leaf component. We'll use React's built-in usync external store hook. It takes two callbacks, one used to subscribe to the store and watch for changes, and another to get the current value from the store. Whenever the store changes, React will use that as a signal to update the hook's internal state using the current value of the store, causing the component to re-render.

Now the intermediate components don't need to re-render at all. Only the leaf components get notified when the store changes, so no other components get re-rendered. By just passing around a static store object, we've broken out of the limitations of React's useState hook while keeping a similar API. Combined with effect components, we can prepare state and then pass it around without re-rendering the ancestors at all. By passing store.set to our effect component instead of React's setState callback, we never need to work with useState in our top component and therefore never need to re-render it. DataModel stores are also usable outside of React or any UI library, so you can manage reactive state in data model classes, in a worker, or even on the server. This is actually very similar to a performance optimization Redux does under the hook. Redux is just passing around a static store reference using React context.

React's state isn't involved until you've called Redux's useSelector hook. But swap stores are much closer to the useState API, so they need less boilerplate, especially for simple state. By the way, this does also mean that Redux will have better performance than React's built-in useReducer hook, especially if you have a giant reducer store.

Changing the value with useReducer will re-render the entire tree when anything changes, because it's being translated into React state at the top of the tree. In contrast, Redux's useSelector will just update grandchildren when the selected state changes. Now you might have also heard of this cool new API called Signals in other libraries like React and Solid. SlotStore has a somewhat similar API to Signals, so does that mean you could just use Signals instead? Yes. But, you know what, I like SlotStores. They have an extra feature over most Signal libraries. They know how many listeners are attached and can initiate and clean up based on whether or not they have any listeners.

This is really great for wrapping other APIs as a nice generic observable system, such as MatchMedia for listening to CSS media queries. We can wrap MatchMedia into a store that only will attack an event listener once, once at least one component has started subscribing to the store. Any subsequent components will not trigger this callback, so that we don't need to worry about tons of event listeners attached to original MatchMedia. Once all the components have unmounted and unsubscribed, we can clean up our event listener and avoid memory leaks. This feature gives SlotStore an edge over other Signal libraries, even over Slot's new prunes. But, a recent TC39 proposal to standardize Signals inside the JavaScript language also includes this extra feature. So, we might see it come to other Signal libraries, too.

These are all real tricks I use to improve performance on Microsoft products, like Microsoft Loop, while avoiding big refactors and rewrites. I'm sharing them with you so that you, too, can learn the art of ignoring best practices, but to improve your React performance. Thank you for listening. You can find my blog online at tigeroaks.com, and check out the app I work on at loop.microsoft.com.