When should you NOT use React memo?
JavascriptReactjsJavascript Problem Overview
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?
A situation like this seems like an obvious choice for implementation:
// NameComponent.js
import React from "react";
const NameComponent = ({ name }) => <div>{name}</div>;
export default React.memo(NameComponent);
// CountComponent.js
import React from "react";
const CountComponent = ({ count }) => <div>{count}</div>;
export default CountComponent;
// App.js
import React from "react";
import NameComponent from "./NameComponent";
import CountComponent from "./CountComponent";
class App extends Component {
state = {
name: "Keith",
count: 0
};
handleClick = e => {
this.setState({ count: this.state.count + 1 });
};
render() {
return (
<div>
<NameComponent name={this.state.name} />
<CountComponent count={this.state.count} />
<button onClick={this.handleClick}>Add Count</button>
</div>
);
}
}
Because name
will never change in this context, it makes sense to memoize.
But what about a situation where props change frequently?
What if I added another button that changed something else in state and triggered a re-render, would it make sense to wrap CountComponent
in memo, even though this component by design is meant to update frequently?
I guess my main question is as long as everything remains pure, is there ever a situation to not wrap a functional component with React Memo?
Javascript Solutions
Solution 1 - Javascript
React.memo
LITERALLY, as comparing the tree returned by the Component is always more expensive than comparing a pair of props
properties
You should always use So don't listen to anyone and wrap ALL functional components in React.memo
. React.memo
was originally intended to be built into the core of functional components, but it is not used by default due to the loss of backward compatibility. (Since it compares the object superficially, and you MAYBE are using the nested properties of the sub-object in the component) =)
That's it, this is the ONLY REASON why React doesn't use memo Automatically. =)
In fact, they could make version 17.0.0, which would BREAK backward compatibility, and make React.memo
the default, and make some kind of function to cancel this behavior, for example React.deepProps
=)
Stop listening to theorists, guys =) The rule is simple:
If your component uses DEEP COMPARING PROPS then don't use memo, otherwise ALWAYS use it, comparing TWO OBJECTS is ALWAYS CHEAPER than calling React.createElement()
and comparing two trees, creating FiberNodes, and so on.
Theorists talk about what they themselves do not know, they have not analyzed the react code, they do not understand FRP and they do not understand what they're advising =)
P.S. if your component is using children
prop, React.memo
will not work, because children
prop always makes a new array. But It is better not to bother about this, and even such components should ALSO be wrapped in React.memo
, since the computing resources are negligible.
Solution 2 - Javascript
All react components implement the shouldComponentUpdate()
method. By default (components extending React.Component
), this returns true, always. The change that memoizing a component (through React.memo
for functional components or extending React.PureComponent
for class components) introduces is an implementation of the shouldComponentUpdate()
method - which does the shallow comparison of the state and props.
Looking at the documentation on the component lifecycle methods, shouldComponentUpdate()
is always called before the render happens, this means that memoizing a component will include this additional shallow comparison on every update.
Taking this into consideration, memoizing a component does have performance effects, and the magnitude of these effects should be determined through profiling your application and determining whether it works better with or without the memoizing.
To answer your question, I don't think there's an explicit rule when you should or should not memoize components, however I think the same principle should be applied as when deciding whether or not you should override shouldComponentUpdate()
: find performance issues through the suggested profiling tools and identify whether or not you need to optimise a component.
Solution 3 - Javascript
> Is there ever going to be a situation that negatively impacts performance?
Yes. You may end up with worse performance, if all components are mindlessly wrapped by React.memo
.
It is not needed in many cases. To give it a try with a performance critical component, do some measures first, add memoization and then measure again to see if added complexity was worth it.
React.memo
?
What is the cost of A memoized component compares old with news props to decide, if to re-render - each render cycle.
A plain component does not care and just renders, after props/state change in a parent.
Take a look at React shallowEqual
implementation, which is invoked in updateMemoComponent
.
React memo
?
When NOT use There are no hard rules. Things, that affect React.memo
negatively:
- component often re-renders with props, that have changed anyway
- component is cheap to re-render
- comparison function is expensive to perform
Ad 1: In this case, React.memo
cannot prevent a re-render, but had to do additional calculations.
Ad 2: Added comparison cost is not worth it for a "simple" component in terms of render, reconcile, DOM change and side-effect costs.
Ad 3: The more props, the more calculations. You also can pass in a more complex custom comparer.
React.memo
?
When complement It only checks props, not context changes or state changes from inside. React.memo
is also useless, if the memoized component has non-primitive children
. useMemo
can complement memo
here, like:
// inside React.memo component
const ctxVal = useContext(MyContext); // context change normally trigger re-render
return useMemo(() => <Child />, [customDep]) // prevent re-render of children
Solution 4 - Javascript
The same question has an answer by markerikson on the React GitHub issue tracker. It got way more thumbs up than the answers here.
> 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.
Solution 5 - Javascript
The idea is to avoid using memoization, for data which has the possibility of changing very often. As stated in the blog, this also includes callbacks which depends on such types of data. For example functions such as
> <Foo onClick={() => handle(visitCount)}/>
I really enjoyed this simplistic read. The examples are great. https://dmitripavlutin.com/use-react-memo-wisely/
Solution 6 - Javascript
I think the short answer is: React.memo does to Functional Components what React.PureComponent does to Class Components. In that sense, when you use memo it will evaluate if the props to that functional component have changed, if so, then it will execute the return of the fuction, otherwise it will not, avoiding re-render of the component.
import React, { memo } from 'react';
const Component = () => {
debugger;
return (
<div>Hello World!</div>
);
};
const MemoComponent = memo(() => {
debugger;
return (
<div>Hello World!</div>
);
});
If you use Component
as child component of a container that updates, everytime the parent updates it will re-render (debugger will trigger everytime).
In the other hand if you use MemoComponent
it will not re-render (debugger will only trigger in the first render).
In this example that happens because the functional component doesn't have props, in case it had props it will happen only if the props change.
Solution 7 - Javascript
"Remember that the function passed to useMemo runs during rendering. Don’t do anything there that you wouldn’t normally do while rendering. For example, side effects belong in useEffect, not useMemo.
You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance. (For rare cases when a value must never be recomputed, you can lazily initialize a ref.)"
https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-functions-from-the-list-of-dependencies