Q: When should you NOT use React memo?

[rlesniak]

I've been playing around with React 16.6.0 recently and I love the idea of React Memo, but I've been unable to find anything regarding scenarios best suited to implement it. The React docs (https://reactjs.org/docs/react-api.html#reactmemo) don't seem to suggest any implications from just throwing it on all of your functional components. Because it does a shallow comparison to figure out if it needs to re-render, is there ever going to be a situation that negatively impacts performance?

And second question: as long as everything remains pure, is there ever a situation to not wrap a functional component with React Memo?

Thank you.

[markerikson]

I would assume that the same general advice applies for React.memo as it does for shouldComponentUpdate and PureComponent: doing comparisons does have a small cost, and there's scenarios where a component would never memoize properly (especially if it makes use of props.children). So, don't just automatically wrap everything everywhere. See how your app behaves in production mode, use React's profiling builds and the DevTools profiler to see where bottlenecks are, and strategically use these tools to optimize parts of the component tree that will actually benefit from these optimizations.

[G-Rath]

I would also imagine it'd apply to the useMemo hook.

The main thing I'm interested in relating to this question is about the cost of class initialisation (and similar) - It's something that I see just dropped in in couple of places of the React docs by Facebook, without any evidence or references. I'm not challenging Facebook, but I'd love to read more about it, so I can know what they clearly do, and thus optimize my builds.

They do the same with hooks, where they state:

For example, classes don’t minify very well, and they make hot reloading flaky and unreliable.

Which is the first I've heard of classes messing with hot reloading - in my experience I've not actually ever had a working hot reloading system that actually does swap out small chunks of code. That could be b/c I use classes everywhere, but I've never in my readings come across anything saying 'classes are screwing up my hot reloading' or 'hey classes cost you ~5kb more than functional components'.

I think a big factor in the answer on when to use memo relates to how/when React actually does component mounting/initialization. I know that information is on hand in the React docs (and other places), but it's not really mentioned "around" memo talks, making it really easy to forget.

From what I remember, it's something like " does not create a whole new element everytime - thats why mount methods & constructors don't get called every render. Instead, React does some magic to somehow re-use or compare the instance if it exists". This could be completely wrong or muddled, but that's also kind of my point.

I'm not trying to derail this issue at all (And I do apologize for my ramblings in this comment), but I do feel it'd be nice to have some clear cut examples and discussion about where it's costing you (and saving you) to memo. It'd especially be cool to have some extreme examples, with really slow components that are "magically" speed up with memo 😁

[markerikson]

useMemo has a different use case than React.memo / shouldComponentUpdate / PureComponent. It's not about preventing an entire component from re-rendering, it's about simply memoizing some data. Very unrelated in usage. The only similarity is that React.memo() and useMemo() both involve "if you see the same inputs as last time, don't do any extra work - return what you had before", but React.memo is for wrapping up entire components, and useMemo() is for whatever you want to return from the callback.

I'm not sure what "class initialization" has to do with React.memo. If I wrap a class component in React.memo and render <MemoizedClassComponent />, the class instance gets created either way. The difference is that there's an invisible extra layer in the component tree, and it won't re-render as often depending on the incoming props.

Classes definitely make hot reloading more difficult, because of trying to swap out prototypes and stuff. I'm not clear on all the nitty-gritty details, but look through the https://github.com/gaearon/react-hot-loader repo to see all the complexities involved.

Overall, the React team has frequently emphasized on social media that "wrapping everything in a PureComponent is a bad idea", but I agree it'd be nice to actually have that in the docs.

As far as I know, everything in https://reactjs.org/docs/optimizing-performance.html that relates to shouldComponentUpdate and PureComponent applies to React.memo as well.

You might also want to read some of the articles on optimizing React performance that I have listed at https://github.com/markerikson/react-redux-links/blob/master/react-performance.md .

[G-Rath]

useMemo has a different use case than React.memo / shouldComponentUpdate / PureComponent. It's not about preventing an entire component from re-rendering, it's about simply memoizing some data. Very unrelated in usage. The only similarity is that React.memo() and useMemo() both involve "if you see the same inputs as last time, don't do any extra work - return what you had before", but React.memo is for wrapping up entire components, and useMemo() is for whatever you want to return from the callback.

You're completely right - that was me being stupid. I've been working too hard lately, and it's left my brain in a muddle 😬

I'm not sure what "class initialization" has to do with React.memo

(I actually technically mean instancing - sorry about the confusion)

In the hooks FAQ, they have the question Are Hooks slow because of creating functions in render?
, which they state in the answer:

Hooks avoid a lot of the overhead that classes require, like the cost of creating class instances and binding event handlers in the constructor.

For Facebook to say "the cost of creating class instances" implies to me there is a cost worth mentioning (i.e, compared to the cost of doing something like const array = [], which doestechnicallyy have a cost, but it's so insanely small no one ever talks about it), but in all my readings about props & cons of classes in JS, I've never come across anyone arguing that classes have a 'cost' worth mentioning (which I figured people would jump on, as ES6 classes were a hot topic of debate back when they were introduced).

I'm assuming that the cost is actually one React suffers with classes due to how it works, where the cost is only a factor when you're creating lots of class instances in the space of seconds all the time, but again, this isn't something I recall seeing explored or talked about in detail in the rest of the React documents.

Thanks for the links - I've not encountered them before, despite my best efforts 😕 You've given me some good reading to do!

[markerikson]

In React 15 and earlier, function components were wrapped in classes internally, so there was no real difference in perf behavior.

In React 16, function components are now handled separately, with no class wrapping them. This means there's less overhead to rendering a function component overall than for a class component. References:

Dominic Gannaway:

Functional components should be slightly faster in React 16 as there's no instance created to wrap them (unlike React 15).

Andrew Clark:

Think of all the features class components have that we can totally skip with functional components. Constructors, refs, lifecycles, error handling. The only reason they were the same performance-wise before Fiber was technical debt in the the Stack implementation.

So, in general, an app that consistently renders N function components should take less total time to render than an app that renders N class components. How much less, I have no idea - you'd have to benchmark things.

However, all of that is mostly separate from the original question of "when should I use React.memo()?"

I understood what you meant by "class initialization" - the cost of creating a single instance of a given class component, because you're rendering it for the first time. My point is that that has nothing to do with use of React.memo, because rendering <PlainClassComponent> for the first time has basically the same cost as rendering <MemoWrappedClassComponent> for the first time. In both cases, a class component instance is created.

Also, that hooks FAQ entry is largely there because of the longstanding fear and confusion in the React community over "creating functions in render being bad for performance". See Ryan Florence's post React, Inline Functions, and Performance for thoughts on that topic.

[TidyIQ]

Can someone please explain (like I'm 5) WHY it's a bad idea to wrap all components in React.memo? If the props on a component haven't changed then it shouldn't re-render as it will simply be returning the exact same component as the initial render.

I also don't understand why the react docs say Do not rely on it to “prevent” a render, as this can lead to bugs. What bugs? Why else would you use React.memo if not prevent an unnecessary re-render?

For example, on my main index page I include a <Header> component that takes in title and metaDescription as props. These props never change for the page so the Header component shouldn't re-render whenever something else is changed on the index page (e.g. someone clicks a button that changes state). It seems the only way to do this is by wrapping the Header component in React.memo, but apparently the docs imply this is the incorrect use.

[StoneCypher]

@markerikson -

So, in general, an app that consistently renders N function components should take less total time to render than an app that renders N class components. How much less, I have no idea - you'd have to benchmark things.

Dramatically, it seems.

[lukewlms]

Here's the best info I've found on this. Seems like there are few cases where you wouldn't want to use React.memo, theoretically. Though the significant extra typing in every component seems clunky.

Perhaps your parent component rerenders regularly and your child component does something impure like render the current time or fetch some data... though I'd think hooks would cover both of those well.