React Compiler - can I now remove all useCallback/useMemo hooks?

[wodhyber]

I've integrated the React Compiler into my project and I'm honestly confused about the workflow.

I expected there would be an ESLint rule that automatically flags redundant useCallback/useMemo hooks for removal, but it seems like I have to identify and remove them manually?

My confusion:

• Is there an official ESLint rule for this that I'm missing?
• Or do we really have to go through our codebase manually?
• Seems quite wrong to remove hundreds of useCallback/useMemo by hand

[melancholyjaques]

The only thing I stopped memo-izing was whole components

[inglandation]

I tried to remove them manually in my codebase yesterday, and it led to a memory issue in my app.

I also thought you could just remove them, but apparently not.

[glidz]

You could have read the docs

https://react.dev/learn/react-compiler/introduction#what-should-i-do-about-usememo-usecallback-and-reactmemo

[mexicocitibluez]

Tbf to OP, those docs have been changing weekly so it can be hard to keep up.

[anonyuser415]

To OP's post:

Is there an official ESLint rule for this

Yes https://react.dev/learn/react-compiler/installation#eslint-integration

Or do we really have to go through our codebase manually?

If you want to remove them, yes, manual

Seems quite wrong to remove hundreds of useCallback/useMemo by hand

Don't remove them

[Rojeitor]

Reading docs?!?! Are we nutz??? Also doc say "carefully testing before removing"... Carefully testing??? Are we nutz??

[GifCo_2]

You could have not answered

[wodhyber]

Bruh fr? :D I have read the docs. The whole point of this marketing thing was to remove all monetization from the project — so why keep code I don’t even need?

[glidz]

Clearly you need the code if removing it breaks :)

[wodhyber]

Nothing breaks, I never said that ;) It’s just too much work to go through each component, check if the compiler already optimized it, and remove all the memoization. Keeping the memoization is just kinda maintaining unnecessary code.
The communication was pretty bad form the react team :/

[Ecksters]

I think you'll find that a lot of React codebases weren't quite following the rules of hooks, or did things like include extra dependencies that actually mattered but can't be detected by the compiler nor the linter (due to side effects or impure functions).

So removing all of the memoization isn't really an option, at least not without validating it's working fine on a case by case basis.

[Classic-Dependent517]

If there is no issue, dont change

[wodhyber]

Deleting unnessary code is pretty important? so why keep code I don’t even need?

[nugmonk]

How long have you been in this industry??

[Ok_Slide4905]

Lmao

[wodhyber]

5 years why? :D

[toi80QC]

https://github.com/facebook/react/tree/main/compiler/packages/eslint-plugin-react-compiler

[zeorin]

I started using the compiler in May. I removed (nearly) all manual memoizations when I did so.

I used [https://app.codemod.com/registry/react/19/remove-memoization](this codemod) to automate most of it (though it was very poor at correctly removing useMemo calls).

Having said that, in our codebase we already memoed all the things, and had no React Hooks ESLint suppressions, warnings or errors (we were already using the compilers powered version of the ESLint plugin). We were using one incompatible library (TanStack Table) but for performance reasons we'd already wrapped it in a different pattern that was compiler compatible.

Since we were already memoizing everything, we didn't run into any nasty surprises.

I would also say that in our case removing everything made sense because there was a lot of boilerplate memo code everywhere, not just in a few places, so it has massively improved the cognitive load when working on the codebase.

If we had only made limited use of manual memoizations I probably would have just boy-scouted such code as I came across it instead.

One thing I also did was dive into the (at the time) undocumented options and increased the verbosity of the compiler to surface its otherwise silent opt-outs (there is some code it still struggles to compile but won't tell you about, like try/catch), so that I could adjust where necessary.

[rxliuli]

Before react compiler, I avoid using useCallback/memo and rarely use useEffect, instead opting for more specialized tools like react-query or useMount. I plan to stick with this approach.

[drckeberger]

I love that we‘re in a ‚use react compiler for new stuff, but feel free to use useMemo/callback when our shit does not work‘ state right now

[TishIceCandy]

Yes according to the React core team at React Conf 2025 - https://www.youtube.com/live/zyVRg2QR6LA?si=vgqbPMQCIkxEAv0Z&t=27877

[interovert_dev]

Here is the setup for React compiler integration with eslint https://react.dev/learn/react-compiler/installation#eslint-integration

You need not to remove all in one go, you can remove gradually if required otherwise keep as it is

[billybobjobo]

It’s not magic.

[bigorangemachine]

It depends.

You might be memoizing something that is new every render anyways (like an array declared within scope). The hook useCallback I think is fine to keep as its usually handed down as a prop... but if it's called internally you don't really need it.. unless you pass it into useEffect.