Bug: useMemo hook executes twice

[dmytro-vasylenko]

I'm using useMemo hook with an empty dependency array in a component withlazy + Suspense, so I expect the function inside useMemo will be called once, but sometimes the function is called twice.

No StrictMode, no rerenders.

useMemo(() => {
  console.log('useMemo');
}, []);

React version: 18.2.0

I can't reproduce it with version 17.0.2

Steps To Reproduce

Please, take a look at the simplified example. I could reproduce it on a regular basis after I've added setState call inside useMemo. As the issue is hard to reproduce, there is a script that reloads the page until the bug appears.

Link to code example: https://codesandbox.io/s/smoosh-forest-g6ft5o

Pay attention, that function in useEffect was called once, which is expected behavior, but useMemo was called twice.

In the real project, there is no setState call inside useMemo and no warnings, but anyway I meet the issue every 10-20 page reloads.

If I delete lazy it works as expected. If I drop LongComponent it works as expected.

The current behavior

The function passed to useMemo is executed twice despite the empty dependency array, and the component wasn't rerendered.

console:
  useMemo
  useMemo
  useEffect

The expected behavior

The function passed to useMemo is executed only once.

console:
  useMemo
  useEffect

[gaearon]

Why does it matter if it executes once or twice? Since any function inside useMemo should be pure, it should make no difference. Is this a performance concern, or does it change the behavior in some observable way (when you follow the rules)?

[TheDevCactus]

After playing with the sample you provided the issue is that the setTimeout you are initiating in the useMemo executes before the component has a chance to render. If you increase the timeout on that setTimeout you'll notice the error go away, Or you can swap out the LongComponent for just like a <h1>hi mom</h1>, everything will function as normal.

In the sample you provided the error

This pretty much says the exact problem. Since the setTimeout runs before the initial render your setState calls from within it causes this bunk behavior.

Honestly the contents of the useMemo really feel like the kind of thing I'd put in a useEffect. Especially since there isn't anything being returned from it

[dmytro-vasylenko]

@TheDevCactus I understand that there is a warning, but this is not an error. The example is just a simulation how to make the bug to appear. I hope it will help somehow. React doesn't show any warning or something in my project, so it was hard enough to spot the issue.

[dmytro-vasylenko]

@gaearon Yeah, it causes unpleasant problems with performance, because the returned value from useMemo is an object. I can fix that, but still this behavior seems to me strange and unexpected.

[qiqo]

Why does it matter if it executes once or twice? Since any function inside useMemo should be pure, it should make no difference. Is this a performance concern, or does it change the behavior in some observable way (when you follow the rules)?

just to add that I'm also having this issue now with the same version and found this thread, this is a problem because I use the hook to control debounce to an expensive REST api, and if it is executed twice (which it is now) then that's a problem because the target API is used twice than it should which can cause race conditions transactional issues and at the production cloud level that amounts to twice the consumption on cloud function/serverless apis which eats up half of my paid for allocation.

[832bb9]

this behavior seems to me strange and unexpected

The docs explicitly says:

'You may rely on useMemo as a performance optimization, not as a semantic guarantee.'.

You can try achieve semantic guarantee using https://reactjs.org/docs/hooks-faq.html#how-do-i-implement-getderivedstatefromprops.

[uditalias]

Same here, I'm using a dependency injection framework factory method inside useMemo to create one instance of a model inside my component, using react 18 triggers useMemo few times for no reason.

[832bb9]

Same here, I'm using a dependency injection framework factory method inside useMemo to create one instance of a model inside my component, using react 18 triggers useMemo few times for no reason.

Please check this https://reactjs.org/docs/hooks-faq.html#how-to-create-expensive-objects-lazily. You can manually save this instance to ref on very first render (or even lazily).

[uditalias]

Same here, I'm using a dependency injection framework factory method inside useMemo to create one instance of a model inside my component, using react 18 triggers useMemo few times for no reason.

Please check this https://reactjs.org/docs/hooks-faq.html#how-to-create-expensive-objects-lazily. You can manually save this instance to ref on very first render (or even lazily).

This is gold! thank you!

[rickhanlonii]

I understand that there is a warning, but this is not an error.

@dmytro-vasylenko the message says "warning" but the log level is error and we consider this an error. It's hard to say exactly what's going on here because it's violating a few patterns, so it's not unexpected that we end up needed to re-memoize the value. Are you able to create a repro that's closer to your use case that doesn't error or depend on calling setState inside useMemo to reproduce?

[SpadarShut]

I call URL.createObjectURL and need to revokeObjectURL on unmount.
What would be the way to make sure I can revoke every created blob URl?

[832bb9]

I call URL.createObjectURL and need to revokeObjectURL on unmount.

What would be the way to make sure I can revoke every created blob URl?

Seems like useEffect is what you need.

[kolserdav]

This is a real useMemo in React 18.2.0 bug. Here is a simple example where useMemo is triggered twice for each dependency value.

https://codesandbox.io/s/compassionate-swartz-wd3j94?file=/src/App.js

Or is this normal in strict mode?

[kolserdav]

This is a real useMemo in React 18.2.0 bug. Here is a simple example where useMemo is triggered twice for each dependency value.

https://codesandbox.io/s/compassionate-swartz-wd3j94?file=/src/App.js

Or is this normal in strict mode?

Yes, I see this is normal https://reactjs.org/docs/strict-mode.html

[mhtamun]

Why does it matter if it executes once or twice? Since any function inside useMemo should be pure, it should make no difference. Is this a performance concern, or does it change the behavior in some observable way (when you follow the rules)?

just to add that I'm also having this issue now with the same version and found this thread, this is a problem because I use the hook to control debounce to an expensive REST api, and if it is executed twice (which it is now) then that's a problem because the target API is used twice than it should which can cause race conditions transactional issues and at the production cloud level that amounts to twice the consumption on cloud function/serverless apis which eats up half of my paid for allocation.

I am facing exactly same issue!

[pauldraper]

I call URL.createObjectURL and need to revokeObjectURL on unmount.

This is exactly how I ran into this!

Seems like useEffect is what you need.

useEffect would involve an unnecessary re-render. There's no reason not to be synchronous.

FWIW,

function useObjectUrl(blob) {
  const ref = useRef();
  const dispose = () => ref.current && URL.removeObjectURL(ref.current.url);
  useEffect(() => dispose, []);
  if (ref.current && blob === ref.current.blob) {
    return ref.current.url;
  }
  dispose();
  const url = URL.createObjectURL(blob);
  ref.current = { blob, url };
  return url;
}

[theKashey]

Recently we faced the issue with useMemo being called multiple times, and sometimes more than just 2, with useEffect being called once. Wondering how it's working underneath...

Investigation led us to the moment where React picks the right hook implementation -

react/packages/react-reconciler/src/ReactFiberHooks.js

Lines 543 to 559 in c5b9375

	if (current !== null && current.memoizedState !== null) {
	ReactCurrentDispatcher.current = HooksDispatcherOnUpdateInDEV;
	} else if (hookTypesDev !== null) {
	// This dispatcher handles an edge case where a component is updating,
	// but no stateful hooks have been used.
	// We want to match the production code behavior (which will use HooksDispatcherOnMount),
	// but with the extra DEV validation to ensure hooks ordering hasn't changed.
	// This dispatcher does that.
	ReactCurrentDispatcher.current = HooksDispatcherOnMountWithHookTypesInDEV;
	} else {
	ReactCurrentDispatcher.current = HooksDispatcherOnMountInDEV;
	}
	} else {
	ReactCurrentDispatcher.current =
	current === null || current.memoizedState === null
	? HooksDispatcherOnMount
	: HooksDispatcherOnUpdate;

In our case it was picking HooksDispatcherOnMount where useMemo callback has a direct execution and the only way to pick the branch is not to have memoizedState in the current fiber.

Meaning:

• information stored in useRef like per example above would be discarded. HooksDispatcherOnMount has no "previous state"
• information stored in useState via callback as per https://legacy.reactjs.org/docs/hooks-faq.html#how-to-create-expensive-objects-lazily would be discarded. The same "no previous state" case.

So the only "stable" way to perform operation once is to perform it in useEffect(hello StrictMode) and save in useState causing re-render, or placing components with useMemo a bit more strategically to have them being rendered a little more stable, ie "above Suspense boundaries".

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[kaifaty]

useRef content clears too :(

[kassens]

With Suspense, it's expected that some components re-execute when the suspense resolves (all the components up to the component that suspended). Generally, components need to be designed to be able to re-run or run without mounting, for example when something else rendered before the suspense was resolved.