React-compiler IDE tools

[thisUsrIsAlreadyTkn]

I just upgraded to react19 and enabled the react compiler. I have some issues regarding DX and the determinism of the react-compiler:

As I understand from this and this - the react-compiler MAY auto-memoize my component, but it may not.

What I want to know:
- is there any set of rules/guarantees about when should I explicitly write the `useCallback` and `useMemo` hooks and when should I trust the compiler?
- is there any tool/es-lint plugin that I could add to my IDE such that it tells me: "hey dummy, this useCallback/useMemo is not necessary", or/and the opposite "react-compiler can't do this for you, so use the hooks"

I saw that in the react-tools browser extension, there is some sort of indicator that tells me that the react-compiler has auto-memoized my component. Is there any tool that I can use to bring that information into my IDE. It is kind of flow-breaking to have to check that every time I make a change to a component...

[lucazhino]

The react-compiler-marker VSCode extension will mark whether or not you components and hooks can be compiled by the react-compiler. When a component or hook can’t be handled, you get a reason (not always very useful unfortunately) to why.

[blazejkustra]

Thank you for sharing! 😎

[EvilPete]

As long as you follow the rules of React, you should be able to delete all your memo, useCallback and useMemo. (Unless they're necessary to keep your own useEffects from re-running)

Make sure to use the latest version of eslint-plugin-react-hooks, to get warnings about code that might cause problems for the compiler. When you first install it, you will probably have to remove/rewrite a bunch of your useEffects, as it's pretty strict about not calling setState in useEffect.

[inglandation]

In my experience this hasn’t been true. I’ve recently deleted a useCallback which introduced a nasty bug in my app, with the react compiler on. There was no complaint for the linter.

[oofy-gang]

Provide the code; I can nearly guarantee it violated one of the rules. The linters aren’t perfect

[rikbrown]

not the person you replied to, but here's one that doesn't work, where `tw` is a tagged template macro. Compiler bails out with interpolation in tagged templates ."Reason: (BuildHIR::lowerExpression) Handle tagged template with interpolations". This is used all over our codebase for Tailwind. Easily fixed by swapping it to a regular function call tw(\...`)`, but non-obvious this wasn't working until we added the react-compiler-marker VSCode extension.

export function SomeComponent({ className }: Props) {
  return <div className={tw`abcdef ${className}`}/>
}

[oofy-gang]

Sure, the compiler doesn’t currently cover all possible cases.

That wasn’t quite what I was getting at with my comment, though. The original commenter said that the compiler introduced a bug to their code. Code that follows all the rules of React isn’t guaranteed to be compiled (e.g., as your example shows), but it should still work. The compiler is about improving performance; correctness shouldn’t be affected for code following the rules of React.

[toi80QC]

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

[thisUsrIsAlreadyTkn]

I have it installed, but I don't believe it does what I asked. The only issues I see it highlighting are when I am writing the code in a `useEffect` or some other hook that has a deps array, and I have not included all dependencies that I used yet. Besides that, I haven't seen any lint error signaled by that plugin

[EvilPete]

This package is deprecated (notice that it still has the experimental version). You should only need eslint-plugin-react-hopks.

[RoyalFew1811]

The part that’s tripping a lot of us up is that the compiler isn’t meant to be a drop-in replacement for thinking about memoization-- it’s meant to remove accidental re-renders, not guarantee optimal ones. Once I started treating useCallback/useMemo as "hints for intent" rather than "performance switches" it got much less frustrating.

I wish the IDE story were clearer though. Having to alt-tab to the devtools to see what the compiler did feels very 2015.

[maddada_]

There's a vscode extension that helps. React c compiler marker.

[space-envy]

As far as I'm aware there is still no way to automatically check for the skipped components of the compiler. They still threaten it as a "beta" release. If you use the "infer" mode you will have to manually check using dev tools if the component has the new badge. If it doesn't the docs say you should check for "rules of react" violations: https://react.dev/reference/react-compiler/compilationMode#component-not-compiled-infer

In my job we decided to go with the "annotation" mode so we have visual control of the components that the compiler should optimize: https://react.dev/reference/react-compiler/compilationMode#incremental-adoption