If you're coming in fresh, check out the first in this blog post series onReact.memo and useMemo - What's the difference?. This post will continue where I left off, on when it's appropriate to use andnot useReact.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 theReact Developer Tools profiler to get a sense of how much difference usingReact.memo (or for that matteruseMemo) makes.

Here are some rough rules of thumb on when to think about investigating the use ofReact.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, thePureComponent 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 forReact.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 useReact.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 myprevious 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 theuseCallback 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 withReact.memo.

Another rule of thumb which maybe simplifies the whole thing - just default to not usingReact.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 ReactuseMemo hook.

P.S. Want to chat? I'm onTwitter andInstagram @bionicjulia.