React Compiler 1.0: What Automatic Memoization Changes

The manual memoization era is ending

React Compiler reached version 1.0 in October 2025, and by 2026 it’s become close to the default expectation for new React projects rather than an opt-in experiment. If you’ve spent years sprinkling useMemo, useCallback and React.memo through components to stop unnecessary re-renders, the practical upshot is straightforward: you mostly don’t need to anymore. The compiler does that work for you at build time, and it’s worth understanding exactly what it’s doing before you rip out your existing memoization code.

What the compiler actually does

React Compiler analyses your component code at build time and automatically inserts the equivalent of memoization wherever it determines a value or callback doesn’t need to be recalculated on a given render. It’s not a runtime optimisation layered on top of your existing code – it rewrites the component itself during compilation, using React’s own rules (the Rules of React – no mutating props/state, no side effects during render, and so on) to determine what’s safe to skip.

• Values derived from props/state get automatically cached and only recomputed when their actual dependencies change
• Callback props are automatically stabilised so child components don’t re-render just because a parent passed a “new” function reference
• Components that don’t need to re-render because none of their relevant inputs changed are skipped entirely

What you can stop doing

1. Wrapping every derived value in useMemo “just in case” – the compiler handles this correctly and consistently, without you needing to get the dependency array right by hand.
2. Wrapping callback props in useCallback purely to stop child re-renders – same story, and this was historically one of the most common sources of stale-closure bugs when a dependency was missed.
3. Manually wrapping presentational components in React.memo as a blanket performance habit rather than a deliberate, measured decision.

Where it doesn’t help – and where you still need to think

The compiler optimises re-render behaviour within React’s own rendering model. It has no visibility into genuinely expensive computation that isn’t about re-renders at all – a slow API call, a heavy synchronous calculation on a huge dataset, or layout thrashing caused by DOM measurement. Those still need the same profiling and optimisation techniques as before; the compiler just removes an entire category of manual bookkeeping that used to obscure the real bottlenecks underneath it.

It’s also strict about the Rules of React. Code that technically worked at runtime but broke those rules – mutating a prop directly, calling a hook conditionally, relying on render order side effects – is exactly the kind of thing the compiler either can’t safely optimise or will flag outright. In practice this has turned out to be a genuine benefit: cleaning up rule violations to get the compiler’s benefit tends to also fix latent bugs that were only “working” by accident.

Migrating an existing codebase

• Turn the compiler on and build – it’s designed to be safe to enable incrementally, and it falls back to normal (non-optimised) behaviour for any component it can’t confidently compile
• Don’t do a mass find-and-replace to strip existing useMemo/useCallback calls immediately – they’re redundant once the compiler covers a component, but harmless, so remove them gradually as you touch that code anyway
• Watch the compiler’s build-time diagnostics for components it skipped, since those are exactly the places still relying on manual memoization or breaking a Rules of React constraint

The bigger shift this represents

Manual memoization was always a workaround for a limitation in how React re-rendered by default, not a feature developers actually wanted to write. React Compiler 1.0 landing alongside 2026’s broader push toward meta-frameworks and server-first rendering (Next.js, Nuxt handling routing, data fetching and rendering strategy out of the box) fits a pattern: a lot of the boilerplate that used to define “doing React properly” is quietly becoming the framework’s job instead of the developer’s. Worth adopting sooner rather than later if you’re not already – the main cost is cleaning up any Rules of React violations the compiler surfaces, and that’s cleanup you’d benefit from regardless.