I put off turning on the React Compiler for almost a year. Not because I doubted it would work, but because every time I read the docs I’d think “okay, but my app already memoizes the right things, what would actually change?” and close the tab.<\/p>\n
Then I had a Sunday with nothing to do, so I flipped it on in a real Next.js app I’d been babysitting for about eighteen months. The compiler is stable in React 19<\/a>, the eslint plugin had calmed down, and the worst case was reverting one PR.<\/p>\n What I found is that I’d been writing a lot of memoization that the compiler now does for me, and a few patterns I genuinely hadn’t realized were broken. Here’s a tour of what I deleted, what I kept, and the rough edges that aren’t in the announcement posts.<\/p>\n The marketing line is “automatic memoization.” That’s accurate but underselling. What it actually does is read your component, work out which values derive from which inputs, and emit a version that only recomputes things when the inputs change. Effectively, it inserts the If you’ve read the React Compiler reference<\/a>, you’ve seen the example with a It runs at build time. There’s no runtime cost beyond the slightly larger output, and the output is plain React: hooks, components, no special runtime. That’s the part I trusted most before turning it on.<\/p>\n I went through the codebase the day after enabling the compiler and pulled hand-rolled memoization that no longer earned its keep. Here’s a representative chunk before:<\/p>\n After:<\/p>\n That’s the whole point. The compiler sees that Across the project I removed about forty Two things bit me, and neither is in the headline announcement.<\/p>\n The first is referential equality across hooks I don’t own. If a third-party hook returns a fresh object every render, no compiler in the world can save you. I had a date-range hook that returned The second is I poked at a few of these interactions earlier this year in the React 19 features I actually use six months in<\/a>, if you want a related read.<\/p>\n Here’s what nobody told me clearly: the compiler will silently bail on components it can’t safely transform. That’s correct behavior, since an unmemoized component beats a wrong one, but it means you can ship something you think is compiled and have a quarter of your tree opt out without knowing.<\/p>\nWhat the compiler actually does<\/h2>\n
useMemo<\/code> and useCallback<\/code> calls a careful person would insert, and inserts them in places a careful person wouldn’t bother.<\/p>\n<TodoList><\/code> and a sort callback that the compiler memoizes for you. In a real app the wins are subtler. You stop seeing prop changes that don’t matter trigger child re-renders, and the diff between commits gets smaller. I noticed it most in a few list components where I’d given up on memoization because every parent change blew through it anyway.<\/p>\nThe useMemo and useCallback I deleted<\/h2>\n
function ProjectsTable({ projects, query, sortKey }) {\n const filtered = useMemo(\n () => projects.filter(p => p.name.toLowerCase().includes(query.toLowerCase())),\n [projects, query]\n );\n\n const sorted = useMemo(\n () => [...filtered].sort((a, b) => a[sortKey].localeCompare(b[sortKey])),\n [filtered, sortKey]\n );\n\n const handleRowClick = useCallback(\n (id) => router.push(`\/projects\/${id}`),\n [router]\n );\n\n return <Table rows={sorted} onRowClick={handleRowClick} \/>;\n}\n<\/code><\/pre>\nfunction ProjectsTable({ projects, query, sortKey }) {\n const filtered = projects.filter(p =>\n p.name.toLowerCase().includes(query.toLowerCase())\n );\n const sorted = [...filtered].sort((a, b) =>\n a[sortKey].localeCompare(b[sortKey])\n );\n const handleRowClick = (id) => router.push(`\/projects\/${id}`);\n\n return <Table rows={sorted} onRowClick={handleRowClick} \/>;\n}\n<\/code><\/pre>\nfiltered<\/code> only depends on projects<\/code> and query<\/code>, and that sorted<\/code> only depends on filtered<\/code> and sortKey<\/code>, and emits cached versions. The function identity for handleRowClick<\/code> is now stable across renders unless router<\/code> actually changes.<\/p>\nuseMemo<\/code> and useCallback<\/code> calls. Maybe twelve of them were doing real work; the rest were premature, copy-paste guards I’d added because some prop was getting passed to a memoized child and I didn’t want to think about it. The diff was satisfying in a small petty way.<\/p>\nThe places it didn’t help<\/h2>\n
{ from, to }<\/code> as a new literal each call. The compiler dutifully memoized everything downstream of it, but the inputs themselves changed every render, so nothing was actually cached. The fix was to wrap the hook (or, in my case, replace it with a tiny one that returned a stable reference). Worth checking your dependencies before assuming the compiler magically fixed things.<\/p>\n\/\/ The third-party hook (out of my control)\nfunction useDateRange() {\n \/\/ returns a new object literal every render\n return { from: startOfWeek(new Date()), to: new Date() };\n}\n\n\/\/ My wrapper that gives me a stable reference\nfunction useStableDateRange() {\n const { from, to } = useDateRange();\n return useMemo(\n () => ({ from, to }),\n [from.getTime(), to.getTime()]\n );\n}\n<\/code><\/pre>\nuseEffect<\/code> dependencies. The compiler doesn’t rewrite your effects’ dependency arrays. If you had a nasty effect that re-ran because onChange<\/code> was a new function each render, that’s still a problem, except now onChange<\/code> is stable, so the bug presents differently. I had one effect that used to fire constantly, then started firing once per real change after I enabled the compiler, and that exposed a race I hadn’t noticed before. Net positive, but worth knowing.<\/p>\nThe eslint plugin is the real shipping criterion<\/h2>\n