Deeper Dive Into React.memo
3 min read
If you're coming in fresh, check out the first in this blog post series on React.memo and useMemo - What's the difference?. This post will continue where I left off, on when it's appropriate to use and not use
When to use React.memo
As mentioned in my previous post, React is already super speedy in how it performs its re-renders. If you're going to intercept this process and introduce complexity, you should be sure that the tradeoff is indeed worth it. There are no black and white rules for this as it'll really depend on how you've set up your components and what each component does, but there are some situations where it might make more sense than others. What you'd probably want to do in reality is to measure the performance of your app using the React Developer Tools profiler to get a sense of how much difference using
React.memo (or for that matter
Here are some rough rules of thumb on when to think about investigating the use of
- If given the same inputs, your component always renders the same outputs (i.e. a pure functional component). Remember that if you're using class-based components, this is in effect, the
PureComponentthat React provides.
- If your component renders a large number of things for your UI. e.g. rendering a long list of items.
- If the props being passed into your component are the same, most of the time, especially if...
- The parent component that includes this component has to re-render often, thus causing this component to keep re-rendering.
If you look at the list above, and realise that your component hits all of the points the above, it's probably a great candidate for
React.memo. Essentially if:
- You know that your props never really change much, thus resulting in the same UI items being rendered each time...
- Especially if your component has to do complex, time consuming calculations to decide what to render...
- And there are lots of UI parts for React to do DOM comparisons on...
- Which its parent keeps forcing re-renders on...
... you're on to a winner.
If you do decide to use
React.memo, keep in mind the common 'gotchas'.
React.memouses shallow comparison to compare props. You therefore don't want to pass in non-primatives as props. Refer to my previous blog post for more on this.
- If for instance, you need to pass in a callback function as a prop, be sure to define the function outside and wrap it with the
useCallbackhook to ensure you're constantly passing in the same instance of the function as props.
When not to use React.memo
Remember that forcing React to do the props comparisons before deciding whether to re-render is a cost. Is it faster / more performant to just allow React to do its own thing? If, for instance, you know for sure that your props will constantly be changing, there's no point in wrapping the component with
Another rule of thumb which maybe simplifies the whole thing - just default to not using
React.memo. It's only through noticing poor performance and running profiling checks, that you can then make the informed decision that some sort of caching to prevent unnecessary re-renders is needed.