[Compiler Bug]: Memoization: Compilation skipped because existing memoization could not be preserved

[amanmahajan7]

What kind of issue is this?

• React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
• babel-plugin-react-compiler (build issue installing or using the Babel plugin)
• eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
• react-compiler-healthcheck (build issue installing or using the healthcheck script)

Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhHCA7MAXABAUQA8AHBLASwDcEBhCAW2MzLwF5d6F6IAKAMygY42cpgIkyYKrQZMMLHsFwATAIbZVAGlyYaAG3JwA1rgC+ASlzAAOhly50WPMRgREYMAmUARdatzsUJ4Asly8PJasAHxWtvb2MAjYsHYIEhTUAAqu7lIYAOY8ahrmANxxZtoA2sWqALplthWOOLgAFqoYynq0BsYBuEG0qnp6AEaqxjw85NhckTE2dvG6fUYzc-QAdOTKjcum1auGRg3lGBWJyTB2PBX2ADzKVFH38cAubggeXr4aW-RVMQNlwAjE7st4vEnlRcEYEABPVjAWZcHbKUw6DD6E7IiJg9qdbq9E4g+jmTEAelekPi5gpbwelOelBp9n2FnOtgEQhEYjSpAyCGyXw85AKRT8liWCSSKRUfnOphApiAA

Repro steps

1. Copy the component from the https://react.dev/learn/react-compiler/introduction#before-react-compiler section in the playground
2. Notice useMemo shows a compilation error

Memoization: Compilation skipped because existing memoization could not be preserved

React Compiler has skipped optimizing this component because the existing manual memoization could not be preserved. This value was memoized in source but not in compilation output.

How often does this bug happen?

Every time

What version of React are you using?

latest (I believe)

What version of React Compiler are you using?

latest

[josephsavona]

Thanks for posting. Can you add a bit more detail about what you think is wrong here? For example, i'm not sure if you were surprised that the "before" example from the docs had a lint warning, or think that the error message itself is incorrect, or confusing, etc.

[amanmahajan7]

I have a few questions.

1. Is the error message correct in the "before" example? If yes, then what is the issue and how should it be fixed? I am still pretty new to RC so apologies if I completely misunderstood it.
   This is the output from my local but I can create an example if needed.

Before

After

There is no lint error so I was expecting this component to get optimized.

2. My understanding is if RC can memoize successfully then it should remove useMemo/useCallback/memo from the generated output but I am not seeing that. Same example from above but without useMemo

https://playground.react.dev/#N4Igzg9grgTgxgUxALhHCA7MAXABAUQA8AHBLASwDcEBhCAW2MzLwF5d6F6IAKAMygY42cpgIkyYKrQZMMLHsAA6GXLgAmAQ2yaANCrWYaAG3JwA1ioC+yXMtUbtm2zASb1mYwE9cASWxcANoAugDcBrhGpha2POTqtoLmGBAA7hgAlLisAHy4lBDx4RhWWfZq6Fh4ABaaGOrGtNHm2bhQYLSaxsYARpoWPBFqcQH0tv5cWbl2Q2qRGCZm5iNcAHTxGcVzuFb6DmqBUUvBEZsqEa7YsKqD+7gAPOpUObNqwFo6q-SaxDwr9FM8rdtttHlRcOYEF5WMByKN1uorPNFhYYTxAbhavVGijlnDJkiAPQvO5qDIZKyze6Ep6UElk4qlUIgKxAA

Notice the generated code is still using memo. Is this expected? Let me know if you need more details.

[amanmahajan7]

Any update on this? Thank you!

[iamakulov]

Just stumbled upon this error as well.

Can you add a bit more detail about what you think is wrong here?

I’m personally surprised by the fact that React Compiler refuses to optimize some components that have useMemo() inside (including the very simple one from the docs). My mental model of React Compiler was “useMemo isn’t necessary but is fine as long as you don’t eg put an invalid dep into one.” I’m guessing this model is invalid, but I’m still curious to understand when exactly :)

E.g., in the playground, I can see useMemo() doesn’t deopt if you drop the processedData.map() call (but still reference processedData in some way). Is this because .map() could cause a mutation, so Compiler can’t optimize processedData separately from processedData.map()?

[josephsavona]

Is this because .map() could cause a mutation, so Compiler can’t optimize processedData separately from processedData.map()?

Yup, that's exactly what's happening here. When we have type information (for example if we knew that processedData was an Array), the compiler can do much more inference. For example, checking if the map callback mutates any of the items or not. But in this case we don't know the types and have to assume that processedData.map() may be mutating.

My mental model of React Compiler was “useMemo isn’t necessary but is fine as long as you don’t eg put an invalid dep into one.”

The approach is more: the compiler will guarantee it can memoize at least as much as you manually memoized[1]. If you have no manual memoization, it will try to add more. If there is manual memoization then the compiler will check if the existing memoization matches its inference. If it does, then it rewrites it and can potentially memoize other parts of the code. If not — your memoization doesn't match the compiler's inference — then the compiler skips optimization in order to ensure that your memoization doesn't break.

The reason for this is that developers sometimes need to use useMemo() not just as an optimization but for correctness — to avoid an effect firing too often. By ensuring that we preserve existing memoization, the compiler ensures it doesn't accidentally cause effects to start firing more often than before.

[1] One caveat — the compiler currently prunes existing manual memoization where the result value is known to be a primitive. Primitives can be cheaply compared with === to avoid firing effects or invalidating downstream memoization, so such computations don't strictly need to be memoized. We've gotten feedback on this, though, and are working to ensure we preserve manual memoization of primitives.

[amanmahajan7]

for example if we knew that processedData was an Array), the compiler can do much more inference

Is there a way to inform the compiler about the type?

Also, should memo be removed from the complied output on successful optimization?

[josephsavona]

@amanmahajan7 The compiler does not currently remove memo() around components, that's something we may explore in the future. Currently it removes useMemo() and useCallback() if it optimizes a component/hook.

We do have an internal system for telling the compiler about the types of builtin functions, but that format is very unstable and not something we plan to expose to developers. Instead, longer-term we'd like to integrate with Flow and TypeScript to use their type information to augment the compiler's inference.

[amanmahajan7]

Thanks! Makes sense now.

The compiler does not currently remove memo() around components, that's something we may explore in the future.

I think it will help if this is mentioned in the docs. I tried to use RC in one of my projects and noticed that performance was severely impacted as I removed memo.

[iamakulov]

Thank you! That’s super helpful.

Currently it removes useMemo() and useCallback() if it optimizes a component/hook.

Out of curiosity, what was the reason behind this btw? That is, why bail out completely if it encounters a useMemo() it can’t preserve, rather than preserving it as-is?

I’m adopting RC on a large project right now, and I’m finding that this makes adoption a bit tricky. Writing new code with RC is great – you don’t need to memoize much. But if you stumble upon something that RC didn’t memoize and try to memoize it manually, it suddenly bails out on the whole component, forcing you to memoize everything else inside it.

(A workaround is to do const useMemoRenamed = useMemo and use that for manual memoization without causing deopts, but... bleh.)

[josephsavona]

@iamakulov Yup, great question. First, some context for why the compiler works as it does today. I touched in this in my answer above but expanding on that:

We've aligned on the current approach after exploring a number of alternatives. One of our goals was to allow easily removing useMemo/useCallback after adopting the compiler. To make that work, useMemo/useCallback can't be meaningful to the compiler — we want to compile as if they weren't there. That's why one of the earliest passes in the compiler is to remove manual memoization, and we are very consistent about making sure later passes don't depend on the presence of the original manual memo for any aspect of our inference other than validating whether we preserved manual memoization or not.

We have also experimented with not doing that, and making useMemo/useCallback meaningful to the compiler. However, that had problems — the assumptions the compiler would have to make to preserve the memoization could cause problems in some cases. It's been a while since we looked it into and I don't recall the examples offhand, but it would need more work and makes it then harder to migrate away.

That all said: we hear you that the current approach comes with tradeoffs. I'd love to understand in more detail which cases didn't work and where you needed manual memoization. Can you file issues with some examples? Thanks in advance!

[iamakulov]

Thank you so much for the background! Raised the issue with examples: #34289

[systemadmin-lab]

Compiler Output
Memoization: Compilation skipped because existing memoization could not be preserved

Happens when a component uses manual memoization (React.memo, useMemo, useCallback)
Compiler cannot preserve that memoization during compilation/optimization.
Usually caused by dynamic imports, hot module reload (HMR), or unstable references.
1️⃣ Ensure your component is pure
React.memo only works reliably if props and internal logic are stable.

const MyComponent = React.memo(({ count }) => {
return

{count}

;
});
2️⃣ Avoid memoizing dynamically imported components directly

Wrap after import:

const LazyComponent = React.lazy(() => import("./Component"));
const MemoizedLazy = React.memo(LazyComponent);

3️⃣ Use useMemo / useCallback properly

Only memoize expensive computations or stable callbacks:

const handleClick = React.useCallback(() => setCount(c => c + 1), []);

4️⃣ Update dependencies

Make sure React, Vite/Next.js, and related compiler plugins are up-to-date.

Older versions may fail to preserve memoization.

5️⃣ If all else fails

It’s just a compiler optimization warning, not a runtime error.

You can safely ignore it if the memoized component still works as expected.

💡 TL;DR:

Ensure components are stable and pure

Avoid memoizing dynamic/HMR components

Update React and compiler

Safe to ignore if functionality is correct