If you've struggled to make sense of useMemo and useCallback, you're not alone! I've spoken with so many React devs who have been scratching their heads about these two hooks.
My goal in this blog post is to clear up all of this confusion. We'll learn what they do, why they're useful, and how to get the most out of them.
\nLet's go!
\nIntended audience
\nThis tutorial is written to help beginner/intermediate React developers get more comfortable with React. If you're taking your very first steps with React, you might wish to bookmark this one and come back to it in a few weeks!
\nAlright, so let's start with useMemo.
The fundamental idea with useMemo is that it allows us to “remember” a computed value between renders.
This definition requires some unpacking. In fact, it requires a pretty sophisticated mental model of how React works! So let's address that first.
\nThe main thing that React does is keep our UI in sync with our application state. The tool that it uses to do this is called a “re-render”.
\nEach re-render is a snapshot of what the application's UI should look like at a given moment in time, based on the current application state. We can think of it like a stack of photographs, each one capturing how things looked given a specific value for every state variable.
\nEach “re-render” produces a mental picture of what the DOM should look like, based on the current state. In the little demo above, it's pictured as HTML, but in reality it's a bunch of JS objects. This is sometimes called the “virtual DOM”, if you've heard that term.
\nWe don't directly tell React which DOM nodes need to change. Instead, we tell React what the UI should be based on the current state. By re-rendering, React creates a new snapshot, and it can figure out what needs to change by comparing snapshots, like playing a “find the differences” game.
\nWait, what?
\nI recently published a blog post that explains what a “re-render” is, and why they occur. If you're feeling a bit lost, it might help to read that blog post first, and then come back to this one!
\n\nReact is heavily optimized out of the box, and so in general, re-renders aren't a big deal. But, in certain situations, these snapshots do take a while to create. This can lead to performance problems, like the UI not updating quickly enough after the user performs an action.
\nFundamentally, useMemo and useCallback are tools built to help us optimize re-renders. They do this in two ways:
Reducing the amount of work that needs to be done in a given render.
\nReducing the number of times that a component needs to re-render.
\nLet's talk about these strategies, one at a time.
\nLet's suppose we're building a tool to help users find all of the prime numbers between 0 and selectedNum, where selectedNum is a user-supplied value. A prime number is a number that can only be divided by 1 and itself, like 17.
Here's one possible implementation:
\n\nimport React from 'react';\n\nfunction App() {\n // We hold the user's selected number in state.\n const [selectedNum, setSelectedNum] = React.useState(100);\n \n // We calculate all of the prime numbers between 0 and the\n // user's chosen number, `selectedNum`:\n const allPrimes = [];\n for (let counter = 2; counter < selectedNum; counter++) {\n if (isPrime(counter)) {\n allPrimes.push(counter);\n }\n }\n \n return (\n <>\n <form>\n <label htmlFor=\"num\">Your number:</label>\n <input\n type=\"number\"\n value={selectedNum}\n onChange={(event) => {\n // To prevent computers from exploding,\n // we'll max out at 100k\n let num = Math.min(100_000, Number(event.target.value));\n \n setSelectedNum(num);\n }}\n />\n </form>\n <p>\n There are {allPrimes.length} prime(s) between 1 and {selectedNum}:\n {' '}\n <span className=\"prime-list\">\n {allPrimes.join(', ')}\n </span>\n </p>\n </>\n );\n}\n\n// Helper function that calculates whether a given\n// number is prime or not.\nfunction isPrime(n){\n const max = Math.ceil(Math.sqrt(n));\n \n if (n === 2) {\n return true;\n }\n \n for (let counter = 2; counter <= max; counter++) {\n if (n % counter === 0) {\n return false;\n }\n }\n\n return true;\n}\n\nexport default App;\nI don't expect you to read every line of code here, so here are the relevant highlights:
\nselectedNum.for loop, we manually calculate all of the prime numbers between 0 and selectedNum.selectedNum.This code requires a significant amount of computation. If the user picks a large selectedNum, we'll need to go through tens of thousands of numbers, checking if each one is prime. And, while there are more efficient prime-checking algorithms than the one I used above, it's always going to be computationally intensive.
We do need to perform this calculation sometimes, like when the user picks a new selectedNum. But we could potentially run into some performance problems if we wind up doing this work gratuitously, when it doesn't need to be done.
For example, let's suppose our example also features a digital clock:
\nimport React from 'react';\nimport format from 'date-fns/format';\n\nfunction App() {\n const [selectedNum, setSelectedNum] = React.useState(100);\n \n // `time` is a state variable that changes once per second,\n // so that it's always in sync with the current time.\n const time = useTime();\n \n // Calculate all of the prime numbers.\n // (Unchanged from the earlier example.)\n const allPrimes = [];\n for (let counter = 2; counter < selectedNum; counter++) {\n if (isPrime(counter)) {\n allPrimes.push(counter);\n }\n }\n \n return (\n <>\n <p className=\"clock\">\n {format(time, 'hh:mm:ss a')}\n </p>\n <form>\n <label htmlFor=\"num\">Your number:</label>\n <input\n type=\"number\"\n value={selectedNum}\n onChange={(event) => {\n // To prevent computers from exploding,\n // we'll max out at 100k\n let num = Math.min(100_000, Number(event.target.value));\n \n setSelectedNum(num);\n }}\n />\n </form>\n <p>\n There are {allPrimes.length} prime(s) between 1 and {selectedNum}:\n {' '}\n <span className=\"prime-list\">\n {allPrimes.join(', ')}\n </span>\n </p>\n </>\n );\n}\n\nfunction useTime() {\n const [time, setTime] = React.useState(new Date());\n \n React.useEffect(() => {\n const intervalId = window.setInterval(() => {\n setTime(new Date());\n }, 1000);\n \n return () => {\n window.clearInterval(intervalId);\n }\n }, []);\n \n return time;\n}\n\nfunction isPrime(n){\n const max = Math.ceil(Math.sqrt(n));\n \n if (n === 2) {\n return true;\n }\n \n for (let counter = 2; counter <= max; counter++) {\n if (n % counter === 0) {\n return false;\n }\n }\n\n return true;\n}\n\nexport default App;Our application now has two pieces of state, selectedNum and time. Once per second, the time variable is updated to reflect the current time, and that value is used to render a digital clock in the top-right corner.
Here's the issue: whenever either of these state variables change, we re-run all of those expensive prime-number computations. And because time changes once per second, it means we're constantly re-generating that list of primes, even when the user's selected number hasn't changed!
In JavaScript, we only have one main thread, and we're keeping it super busy by running this code over and over, every single second. It means that the application might feel sluggish as the user tries to do other things, especially on lower-end devices.
\nBut what if we could “skip” these calculations? If we already have the list of primes for a given number, why not re-use that value instead of calculating it from scratch every time?
\nThis is precisely what useMemo allows us to do. Here's what it looks like:
\nconst allPrimes = React.useMemo(() => {\n const result = [];\n\n for (let counter = 2; counter < selectedNum; counter++) {\n if (isPrime(counter)) {\n result.push(counter);\n }\n }\n\n return result;\n}, [selectedNum]);\n\nconst allPrimes = React.useMemo(() => {\n\n const result = [];\n\n for (let counter = 2; counter < selectedNum; counter++) {\n\n if (isPrime(counter)) {\n\n result.push(counter);\n\n }\n\n }\n\n return result;\n\n}, [selectedNum]);\nuseMemo takes two arguments:During mount, when this component is rendered for the very first time, React will invoke this function to run all of this logic, calculating all of the primes. Whatever we return from this function is assigned to the allPrimes variable.
For every subsequent render, however, React has a choice to make. Should it:
\nTo answer this question, React looks at the supplied list of dependencies. Have any of them changed since the previous render? If so, React will rerun the supplied function, to calculate a new value. Otherwise, it'll skip all that work and reuse the previously-calculated value.
\nuseMemo is essentially like a lil’ cache, and the dependencies are the cache invalidation strategy.
In this case, we're essentially saying “recalculate the list of primes only when selectedNum changes”. When the component re-renders for other reasons (eg. the time state variable changing), useMemo ignores the function and passes along the cached value.
This is commonly known as memoization, and it's why this hook is called “useMemo”.
\nHere's a live version of this solution:
\nimport React from 'react';\nimport format from 'date-fns/format';\n\nfunction App() {\n const [selectedNum, setSelectedNum] = React.useState(100);\n const time = useTime();\n \n const allPrimes = React.useMemo(() => {\n const result = [];\n \n for (let counter = 2; counter < selectedNum; counter++) {\n if (isPrime(counter)) {\n result.push(counter);\n }\n }\n \n return result;\n }, [selectedNum]);\n \n return (\n <>\n <p className=\"clock\">\n {format(time, 'hh:mm:ss a')}\n </p>\n <form>\n <label htmlFor=\"num\">Your number:</label>\n <input\n type=\"number\"\n value={selectedNum}\n onChange={(event) => {\n // To prevent computers from exploding,\n // we'll max out at 100k\n let num = Math.min(100_000, Number(event.target.value));\n \n setSelectedNum(num);\n }}\n />\n </form>\n <p>\n There are {allPrimes.length} prime(s) between 1 and {selectedNum}:\n {' '}\n <span className=\"prime-list\">\n {allPrimes.join(', ')}\n </span>\n </p>\n </>\n );\n}\n\nfunction useTime() {\n const [time, setTime] = React.useState(new Date());\n \n React.useEffect(() => {\n const intervalId = window.setInterval(() => {\n setTime(new Date());\n }, 1000);\n \n return () => {\n window.clearInterval(intervalId);\n }\n }, []);\n \n return time;\n}\n\nfunction isPrime(n){\n const max = Math.ceil(Math.sqrt(n));\n \n if (n === 2) {\n return true;\n }\n \n for (let counter = 2; counter <= max; counter++) {\n if (n % counter === 0) {\n return false;\n }\n }\n\n return true;\n}\n\nexport default App;So, the useMemo hook can indeed help us avoid unnecessary calculations here… but is it really the best solution here?
Often, we can avoid the need for useMemo by restructuring things in our application.
Here's one way we could do this:
\nimport React from 'react';\n\nimport Clock from './Clock';\nimport PrimeCalculator from './PrimeCalculator';\n\nfunction App() {\n return (\n <>\n <Clock />\n <PrimeCalculator />\n </>\n );\n}\n\nexport default App;I've extracted two new components, Clock and PrimeCalculator. By branching off from App, these two components each manage their own state. A re-render in one component won't affect the other.
Here's a graph showing this dynamic. Each box represents a component instance, and they flash when they re-render. Try clicking the “Increment” button to see it in action:
\nWe hear a lot about lifting state up, but sometimes, the better approach is to push state down! Each component should have a single responsibility, and in the example above, App was doing two totally-unrelated things.
Now, this won't always be an option. In a large, real-world app, there's lots of state that needs to be lifted up pretty high, and can't be pushed down.
\nI have another trick up my sleeves for this situation.
\nLet's look at an example. Suppose we need the time variable to be lifted up, above PrimeCalculator:
import React from 'react';\nimport { getHours } from 'date-fns';\n\nimport Clock from './Clock';\nimport PrimeCalculator from './PrimeCalculator';\n\n// Transform our PrimeCalculator into a pure component:\nconst PurePrimeCalculator = React.memo(PrimeCalculator);\n\nfunction App() {\n const time = useTime();\n\n // Come up with a suitable background color,\n // based on the time of day:\n const backgroundColor = getBackgroundColorFromTime(time);\n\n return (\n <div style={{ backgroundColor }}>\n <Clock time={time} />\n <PurePrimeCalculator />\n </div>\n );\n}\n\nconst getBackgroundColorFromTime = (time) => {\n const hours = getHours(time);\n \n if (hours < 12) {\n // A light yellow for mornings\n return 'hsl(50deg 100% 90%)';\n } else if (hours < 18) {\n // Dull blue in the afternoon\n return 'hsl(220deg 60% 92%)'\n } else {\n // Deeper blue at night\n return 'hsl(220deg 100% 80%)';\n }\n}\n\nfunction useTime() {\n const [time, setTime] = React.useState(new Date());\n \n React.useEffect(() => {\n const intervalId = window.setInterval(() => {\n setTime(new Date());\n }, 1000);\n \n return () => {\n window.clearInterval(intervalId);\n }\n }, []);\n \n return time;\n}\n\nexport default App;Like a force field, React.memo wraps around our component and protects it from unrelated updates. Our PurePrimeCalculator will only re-render when it receives new data, or when its internal state changes.
This is known as a pure component. Essentially, we're telling React that this component will always produce the same output given the same input, and we can skip the re-renders where nothing's changed.
\nI wrote more about how React.memo works in my recent blog post, “Why React Re-Renders”.
A more conventional approach
\nIn the example above, I'm applying React.memo to the imported PrimeCalculator component.
In truth, this is a bit unusual. I chose to structure it this way so that everything was visible in the same file, to make it easier to understand.
\nIn practice, I often apply React.memo to the component export, like this:
// PrimeCalculator.js\nfunction PrimeCalculator() {\n /* Component stuff here */\n}\n\nexport default React.memo(PrimeCalculator);\n\n// PrimeCalculator.js\n\nfunction PrimeCalculator() {\n\n /* Component stuff here */\n\n}\n\nexport default React.memo(PrimeCalculator);Our PrimeCalculator component will now always be pure, without us having to tinker with it when we go to consume it.
Should we ever need a non-pure version of PrimeCalculator, we can export the underlying component as a named export. I don't think I've ever needed to do this though.
There's an interesting perspective-shift here: Before, we were memoizing the result of a specific computation, calculating the prime numbers. In this case, however, I've memoized the entire component instead.
\nEither way, the expensive calculation stuff will only re-run when the user picks a new selectedNum. But we've optimized the parent component rather than the specific slow lines of code.
I'm not saying that one approach is better than the other; each tool has its spot in the toolbox. But in this specific case, I prefer this approach.
\nNow, if you've ever tried to use pure components in a real-world setting, you've likely noticed something peculiar: Pure components often re-render quite a bit, even when it seems like nothing's changed! 😬
\nThis leads us nicely into the second problem that useMemo solves.
Even more alternatives
\nIn his blog post “Before you memo()”, Dan Abramov shares another approach based around restructuring the app using children, to avoid needing to do any memoization.