Post

Cody
@codey.bsky.social

Yeah, that’s why it’s not in a stable release yet. The implementation for how it should behave when used correctly is complete. But it has gaps for detecting wrong usage. Linters are not enough as linters can be silenced or ignored altogether

Dominik 🔮
@tkdodo.eu

But even if it tells you to use it, did you never have to add a prop to the dependency array? The linter is totally fine with that, but the memoization rarely works if that prop isn't a primitive...

👻 rossipedia 🎃
@rossipedia.com

Yeah that's a bit of a non-trivial situating. Adding props to dependency arrays is adding component coupling. IMO it breaks encapsulation, and to me is a bit of a smell that warrants extra attention. Not to say that it's wrong, just not trivial. no such thing as a free lunch, and all that

Arnaud Barré
@arnaud-barre.bsky.social

Happy to see more people saying that handleChange functions and useCallback are most of the noise. One note: I would put onKeyDown inside the useEffect, it's way more explicit when not use anywhere else.

Arnaud Barré
@arnaud-barre.bsky.social

What is your position regarding the fact that it sometimes said as unsafe for concurrent mode to write/read ref during render? Because sometimes the de-sync during one render can causes issues for me, so I default to use in-render sync.

Dominik 🔮
@tkdodo.eu

the-latest-ref pattern doesn’t read or write refs during render; the in-render sync will likely cause the compiler to not memoize this path, but then again, with the compiler, you can just remove it 😂

Sandro
@sandroroth.com

Lucky you - we use a component library that often re-creates DOM elements when unstable values or callbacks are passed in 🤷‍♂️ 😢

Dominik 🔮
@tkdodo.eu

seems like that component library relies on props being memoized by consumers, which they either need to communicate clearly or ... it's just a bad practice imo. TanStack Table, for example, also relies on some props being memoized, but it's clearly documented.

BellCube
@bellcube.dev

Let the compiler do it for you? You might be interested in the ESLint plugin I finished up yesterday: github.com/BellCubeDev/... Basically, it aims to flag any manual memoization where React Compiler would already be adding memoization for you

github.comGitHub - BellCubeDev/eslint-plugin-react-no-manual-memo: ESLint plugin for React Compiler users to flag any usage of useMemo, useCallback, and React.memo—both to catch instinctive memoization and to b...ESLint plugin for React Compiler users to flag any usage of useMemo, useCallback, and React.memo—both to catch instinctive memoization and to bring memoization up in code reviews if manual memoizat...
Kieran McHugh
@kmc.bsky.social

I think if you’re building a simple app it’s overkill. If like us you’re building a calendar and need buttery smooth mouse interaction performance, a single missing useCallback can cause the whole app to rerender on every mouse move and make it feel atrocious. Just depends on the context really.

Dominik 🔮
@tkdodo.eu

How do you make sure that a single wrong prop doesn't introduce a laggy interaction? Is there a way to test for that? Are you using the react compiler, because it seems like a great fit here

Kieran McHugh
@kmc.bsky.social

I’ve never looked into it properly - some of our work pre dates the compiler. Does it work in dev mode with hot reloading etc? It’s probably not the best code but our dependency arrays are not always equal to everything used in the function so I assumed the compiler wouldn’t be able to handle that

Dominik 🔮
@tkdodo.eu

Not deprecated, no, but if you use the compiler and it works on all cases because you stick to the rules of react and all libs you use do too, then you don't need to use it anymore.