Should you default to React.memo() or useMemo()?

You might have faced slow renders in react application? When such a situation happens we find ourselves inclined to use React.memo or useMemo.

Should you default to React.memo() or useMemo()?

We use React.memo to bail out of re-rendering by wrapping subtree in React.memo. This works pretty well as an optimization patch but with big real-world apps using it mindlessly can make you suffer “death by thousand cuts” and you may end up wrapping everything that you think is slow with React.memo. With this comes using useMemo and useCallback which you may use for memoized computational values, functions, and handlers. This adds to overall code complexity and you may end up running more code for React to determine changed values, compare them and memoize them. Sometimes this might be the only solution but there are approaches which you can try before you memoize things.

Consider the following code sample:

Code sample

In the code example, we have artificially simulated an expensive sub-tree with <SlowSubtree /> component. Which gets re-rendered on a change in input. As we type in input we set the name state thus causing a re-render of App component, which then renders <SlowSubtree />. The quick fix here is wrapping SlowSubtreecomponent in a React.memo as shown below:

Quick fix just memo() it!

React.memo() is a quick fix but can we avoid using it? Following are some approaches:

Debounce set-state

In the example, we are setting the name state with every keystroke and causing re-rendering each time input changes, setting the state on every keystroke is wastage here. What we can do is we can debounce set state calls to prevent rendering with each keystroke. I consider this as a bit of a hacky approach but I’ve put this here to bring this to your notice.

Debounce set state to prevent render on every keystroke

State relocation

Note that the SlowSubtree the component renders because of a state change in the parent component. The changing part here is name state with <input/> while SlowSubtree is not changing. We can split and move state down in its separate component like shown below:

Move state down in its own component

Render as a child

It is not required to move the state down in its own NameInput component we can also move the state up and leverage a pattern called render as child.
This pattern is very similar to the render props approach but instead of passing components to a render prop, we use props.children instead. Here we will lift the state up in its own component and wrap SlowSubtree component with it.

Move state up and render as a child

When name state changed NameComponent re-render but as it still gets the same children prop as last time so React doesn’t need to visit SlowSubtreesubtree. And as a result <SlowSubtree /> doesn’t re-render.

I have personally used this approach many times to prevent the re-rendering of child subtree. This pattern is used in layout components where the wrapper decided the layout and styles of its children. For example Material-UI Card component.

Conclusion:

Before you use a React.memo() or useMemo() again you should stop and think to see if you can split part that changes from the parts that don’t change. So take into account if state relocation can help before you settle with the memo.