Are there any benefits in using useMemo
(e.g. for an intensive function call) instead of using a combination of useEffect
and useState
?
Here are two custom hooks that work exactly the same on first sight, besides useMemo
‘s return value being null
on the first render:
useEffect & useState
import { expensiveCalculation } from "foo"; function useCalculate(someNumber: number): number | null { const [result, setResult] = useState<number | null>(null); useEffect(() => { setResult(expensiveCalculation(someNumber)); }, [someNumber]); return result; }
useMemo
import { expensiveCalculation } from "foo"; function useCalculateWithMemo(someNumber: number): number { return useMemo(() => { return expensiveCalculation(someNumber); }, [someNumber]); };
Both calculate the result each time their parameter someNumber
changes, where is the memoization of useMemo
kicking in?
Advertisement
Answer
The useEffect
and setState
will cause extra renders on every change: the first render will “lag behind” with stale data and then it’ll immediately queue up an additional render with the new data.
Suppose we have:
// Maybe I'm running this on a literal potato function expensiveCalculation(x) { return x + 1; };
Lets suppose x
is initially 0:
- The
useMemo
version immediately renders1
. - The
useEffect
version rendersnull
, then after the component renders the effect runs, changes the state, and queues up a new render with1
.
Then if we change x
to 2:
- The
useMemo
runs and3
is rendered. - The
useEffect
version runs, and renders1
again, then the effect triggers and the component reruns with the correct value of3
.
In terms of how often expensiveCalculation
runs, the two have identical behavior, but the useEffect
version is causing twice as much rendering which is bad for performance for other reasons.
Plus, the useMemo
version is just cleaner and more readable, IMO. It doesn’t introduce unnecessary mutable state and has fewer moving parts.
So you’re better off just using useMemo
here.