It is not a runtime thing. It doesn’t watch your components and decide at render time what to cache. It reads your source code at build time, figures out which values and functions are stable across renders, and rewrites the output to memoize them automatically. Think of it like a really opinionated linter that also fixes the problems it finds.<\/p>\n
What it isn’t: magic. It can’t fix components that violate the rules of React<\/a>. If you’re mutating props, reading from mutable globals, or doing side effects during render, the compiler will either skip your component or bail out. It has a strict mode that warns you about these things, which is actually one of the best parts: it forces you to write cleaner React whether you use the compiler output or not.<\/p>\n Here’s a component I had in production. It’s a product card that receives a price object and a callback for adding to cart:<\/p>\n Three hooks and a wrapper, all doing the same job: “please don’t recompute this unless the inputs change.” I had to manually track every dependency array and keep them in sync. Miss one, and you get stale data. Add an extra, and the memoization is pointless.<\/p>\n Here’s the same component written for the compiler:<\/p>\n Same behavior. Same performance. Less code. The compiler sees that If you’re on Next.js 15+, it’s one line in For Vite or a custom Webpack setup, you add the Babel plugin:<\/p>\n The compiler runs on every component by default. If it can’t safely optimize a component (because it detects a rules violation), it skips that component and moves on. Your app still works. You can also opt in gradually by adding One thing that tripped me up: the compiler needs React 19. If you’re still on 18, you need to upgrade first. The React 19 upgrade guide<\/a> covers the breaking changes, and most of them are minor. The biggest one for me was the ref callback cleanup function, which took about 20 minutes to fix across the whole app.<\/p>\n I ran the compiler on three projects over the past couple months. Here’s what I found.<\/p>\n It helps a lot when you have deeply nested component trees where parent re-renders cascade down. The kind of app where you’d normally reach for React.memo on five or six child components. The compiler handles all of that, and it’s smarter about it than most developers are. It can memoize individual JSX subtrees within a component, not just the whole thing.<\/p>\n It also helps when you have derived state. If you’re computing something from props and using it in the render, the compiler memoizes that computation with the right granularity. No more second-guessing whether your useMemo dependency array is correct.<\/p>\n Where it doesn’t help: components with genuine side effects during render, components that rely on mutable refs for render logic, and components that read from external stores without useSyncExternalStore. The compiler can’t optimize what it can’t prove is pure. It also won’t help with expensive initial renders, because the cost is in the first computation, not the re-computation.<\/p>\n I measured render times on a dashboard page with about 40 components. Before the compiler, with manual memoization in place, a filter change took about 180ms of React work. After switching to the compiler (and removing all the manual memos), the same interaction took about 165ms. Not dramatic, but the code is significantly easier to read now. That’s the real win.<\/p>\n Before you turn on the compiler, install Fixing those four components took about an hour. After that, the compiler optimized every component in the project without a single bail-out.<\/p>\n This is actually my favorite side effect of the compiler existing. Even if you decide not to use it, the eslint plugin pushes you toward writing React components that are easier to reason about. Pure functions with predictable outputs from their inputs. That’s been the React mental model since day one, but before the compiler there was no tool that actually enforced it.<\/p>\n If you’re starting a new project on React 19, yes, turn it on. There’s no downside. You write simpler code and the compiler handles the optimization.<\/p>\n If you have an existing project, the migration path is low-risk but not zero-effort. Upgrade to React 19, run the eslint plugin, fix the violations, enable the compiler, remove your manual useMemo\/useCallback\/React.memo calls. I did this on a ~200 component project and it took a weekend. Most of the time was the React 19 upgrade itself, not the compiler.<\/p>\n If you’re on React Native, compiler support is still experimental as of early 2026. It works in some setups but the team hasn’t officially blessed it for production RN apps yet.<\/p>\n The practical takeaway: the React Compiler is the best thing to happen to React DX in years. It doesn’t change what React is. It removes the tedious parts of writing it correctly. If you’ve been putting off the React 19 upgrade, this is the reason to stop procrastinating. I wrote about how I approach evaluating new tools<\/a> on this blog before, and the compiler passed every test I care about: it solves a real problem, it fails gracefully, and the code it produces is something I’d write by hand if I had infinite patience.<\/p>\nThe memoization tax you’ve been paying<\/h2>\n
![\"React](\"https:\/\/abrarqasim.com\/blog\/wp-content\/uploads\/2026\/04\/react-compiler-what-it-does-to-your-code-inline-1776142872.png\")
<\/p>\n\/\/ Before: React 18 with manual memoization\nconst ProductCard = React.memo(function ProductCard({ product, onAddToCart }) {\n const formattedPrice = useMemo(\n () => formatCurrency(product.price, product.currency),\n [product.price, product.currency]\n );\n\n const handleClick = useCallback(() => {\n onAddToCart(product.id, 1);\n }, [onAddToCart, product.id]);\n\n const tagList = useMemo(\n () => product.tags.filter(t => t.featured).map(t => t.label),\n [product.tags]\n );\n\n return (\n <div className="card">\n <h3>{product.name}<\/h3>\n <span>{formattedPrice}<\/span>\n <TagList tags={tagList} \/>\n <button onClick={handleClick}>Add to cart<\/button>\n <\/div>\n );\n});\n<\/code><\/pre>\n\/\/ After: React 19 with the compiler\nfunction ProductCard({ product, onAddToCart }) {\n const formattedPrice = formatCurrency(product.price, product.currency);\n\n const handleClick = () => {\n onAddToCart(product.id, 1);\n };\n\n const tagList = product.tags.filter(t => t.featured).map(t => t.label);\n\n return (\n <div className="card">\n <h3>{product.name}<\/h3>\n <span>{formattedPrice}<\/span>\n <TagList tags={tagList} \/>\n <button onClick={handleClick}>Add to cart<\/button>\n <\/div>\n );\n}\n<\/code><\/pre>\nformattedPrice<\/code> only depends on product.price<\/code> and product.currency<\/code>, so it memoizes the computation. It sees handleClick<\/code> closes over onAddToCart<\/code> and product.id<\/code>, so it caches the function reference. It sees the filtered tagList<\/code> depends on product.tags<\/code>, so it memoizes that too. All without me writing a single dependency array.<\/p>\nHow to turn it on<\/h2>\n
next.config.js<\/code>:<\/p>\n\/\/ next.config.js\nmodule.exports = {\n experimental: {\n reactCompiler: true,\n },\n};\n<\/code><\/pre>\nnpm install -D babel-plugin-react-compiler\n<\/code><\/pre>\n\/\/ babel.config.js\nmodule.exports = {\n plugins: [\n ['babel-plugin-react-compiler', {}],\n ],\n};\n<\/code><\/pre>\n'use memo'<\/code> directives to specific files, though I haven’t found that necessary in practice.<\/p>\nWhere the compiler actually helps (and where it doesn’t)<\/h2>\n
The eslint plugin you should install first<\/h2>\n
eslint-plugin-react-compiler<\/code>. It flags components that violate the rules of React and would cause the compiler to bail out. I ran it on that production codebase and found 4 components with issues: two were mutating objects during render, one was reading from a module-level variable that changed, and one had a conditional hook call hidden behind an early return.<\/p>\nShould you adopt it now<\/h2>\n