Deeper Dive Into React.memo
Tags: react
Published: 2021-09-19 12:06:42

---
title: Deeper Dive Into React.memo
published: true
date: 2021-09-19 00:00:00 UTC
tags: react
description: When to use and not use React.memo
canonical_url: https://bionicjulia.com/blog/deeper-dive-into-react-memo
---

If you're coming in fresh, check out the first in this blog post series on [React.memo and useMemo - What's the difference?](https://bionicjulia.com/blog/react-memo-and-usememo-whats-the-difference). This post will continue where I left off, on when it's appropriate to use and _not_ use `React.memo`.

### 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](https://reactjs.org/docs/optimizing-performance.html#profiling-components-with-the-devtools-profiler) to get a sense of how much difference using `React.memo` (or for that matter `useMemo`) makes.

Here are some rough rules of thumb on when to think about investigating the use of `React.memo`.

- 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 `PureComponent` that 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.memo` uses shallow comparison to compare props. You therefore don't want to pass in non-primatives as props. Refer to my [previous blog post](https://bionicjulia.com/blog/react-memo-and-usememo-whats-the-difference) 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 `useCallback` hook 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 `React.memo`.

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.

Next up, when to use and not use the React `useMemo` hook.

P.S. Want to chat? I'm on [Twitter](https://twitter.com/bionicjulia) and [Instagram @bionicjulia](https://instagram.com/bionicjulia).