React 19: What Actually Changed and What You Should Use Now

The Big Picture: What React 19 Actually Ships

React 19 went stable in late 2024, but a lot of teams are still running 18.x in 2026 because nobody had time to read the changelog. That's fair. Let me save you the hour.

The headline features are the React Compiler (formerly React Forget), the new Actions API for async mutations, a set of new hooks (useActionState, useFormStatus, useOptimistic), and first-class support for document metadata like <title> and <meta> directly in your components. Server Components also graduated from experimental to fully supported — no asterisk.

Honestly, the compiler alone justifies the upgrade for most apps. It eliminates the need to manually sprinkle useMemo, useCallback, and React.memo across your codebase. That's not a small thing — it's years of accumulated defensive code you can start deleting.

Worth noting: not all of this is zero-config. The compiler ships as a Babel plugin and a Vite plugin, and you need to opt in explicitly. We'll get to that.

The React Compiler: Stop Writing useMemo by Hand

The React Compiler is a static analysis tool that automatically memoizes your components and hooks at build time. You write normal code. The compiler figures out what's stable and what isn't. No more useCallback(() => fn, [dep1, dep2]) chains that go stale the moment someone adds a prop.

To enable it in a Vite project you add roughly 10 lines of config:

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { babel } from '@rollup/plugin-babel';

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: [['babel-plugin-react-compiler', {}]],
      },
    }),
  ],
});

In practice, you'll hit a few components the compiler can't handle — usually ones with impure side-effects in render or manual ref mutations. The compiler emits a warning and skips those files rather than blowing up your build, which is a sane default. You can add 'use no memo' at the top of a file to opt out explicitly.

One more thing — the React team ships a react-compiler-healthcheck CLI you can run before upgrading to see how much of your codebase is compatible. Run it. It takes 30 seconds and saves you from surprise.

Actions API: Async Mutations Without the Boilerplate

Before React 19, every form submission or async mutation meant writing the same three-state dance: isLoading, error, data. You've written it a hundred times. Actions collapse that into a single pattern.

An Action is just an async function you pass to a <form> or trigger manually. React tracks the pending state for you. Pair it with useActionState and you get the loading/error/result tuple without any manual state:

import { useActionState } from 'react';

async function submitContact(prevState, formData) {
  const email = formData.get('email');
  const res = await fetch('/api/contact', {
    method: 'POST',
    body: JSON.stringify({ email }),
  });
  if (!res.ok) return { error: 'Something went wrong' };
  return { success: true };
}

export function ContactForm() {
  const [state, action, isPending] = useActionState(submitContact, null);

  return (
    <form action={action}>
      <input name="email" type="email" required />
      <button disabled={isPending}>
        {isPending ? 'Sending...' : 'Send'}
      </button>
      {state?.error && <p style={{ color: 'red' }}>{state.error}</p>}
      {state?.success && <p>Done!</p>}
    </form>
  );
}

That's it. No useState, no useEffect, no manual error boundary wiring. The isPending boolean comes straight from React's transition system, which means it also integrates cleanly with <Suspense> if you're using it.

That said, Actions work best for mutations that map to a form. If you're doing programmatic data fetching, useOptimistic and startTransition are probably more relevant — but Actions cover a huge percentage of real-world form patterns.

useOptimistic: Update the UI Before the Server Responds

useOptimistic is a hook for the classic optimistic update pattern — show the user the success state immediately, then reconcile with whatever the server actually returns. Instagram has done this since 2013. Now it's baked into React.

The API is straightforward. You give it the current state and a function that describes how to apply an optimistic update. React manages the rollback if the async operation fails:

const [optimisticLikes, addOptimisticLike] = useOptimistic(
  likes,
  (currentLikes, newLike) => [...currentLikes, newLike]
);

Call addOptimisticLike(tempItem) inside a transition and React renders the optimistic state immediately. When your server call settles, it swaps in the real data. If it throws, the optimistic state disappears and the original stays. Clean.

Document Metadata and Stylesheets in JSX

This one's small but genuinely useful. In React 19, you can render <title>, <meta>, and <link> tags inside any component and React will hoist them to <head> automatically. No more react-helmet dependency for basic SEO metadata.

function ProductPage({ product }) {
  return (
    <>
      <title>{product.name} — My Store</title>
      <meta name="description" content={product.description} />
      <article>{product.name}</article>
    </>
  );
}

React deduplicates <title> tags so the last one rendered wins — which is what you want with nested routes. For stylesheets, you can now pass a precedence prop to <link rel="stylesheet"> and React will order them correctly, even across concurrent renders. That's a problem that used to require a lot of framework-level plumbing.

Look, it's not glamorous. But if you've ever wrestled with helmet conflicts in a Next.js app or debugged why your OG tags weren't updating, you'll appreciate that this is now Just React.

What to Actually Upgrade and When

If you're on React 18.x and your app is stable, there's no fire. React 19 is backwards-compatible for the vast majority of code. The breaking changes are mostly around legacy context API, ReactDOM.render (already deprecated in 18), and some ref callback timing tweaks.

The upgrade path for most apps built after 2022 is: bump the package version, run the compiler health check, enable the compiler plugin, fix the handful of files it flags, and ship. Depending on your app size, that's a half-day to two days of work.

Where you'll feel the benefit fastest is in component-heavy dashboards and design systems. If you're building with a UI library like Empire UI, or composing a lot of animated and stateful components, the automatic memoization from the compiler cuts re-render overhead without any manual tuning. Less profiling, less React.memo wrapping, more building.

If your team is still on class components — upgrade the React version anyway, but don't block that on a class-to-hooks migration. Those are separate decisions.

One more thing — Server Components in React 19 are stable, but they still require a framework (Next.js App Router, Remix, or a custom RSC setup) to actually run. You can't drop them into a plain Vite SPA. Keep that in mind before you get excited in a PR description.

React 19 in the Context of Modern UI Development

The broader shift React 19 represents is moving more complexity into the framework itself. Manual memoization, form state management, metadata hoisting — these were all app-level concerns you solved with third-party libraries or hand-rolled utilities. Now they're first-class primitives.

That doesn't mean the ecosystem collapses. Libraries like TanStack Query are still the right call for complex server state. Animation libraries, component libraries, and design systems built on React don't need to change much — the compiler works transparently underneath.

What it does mean is that the floor gets higher. A junior dev writing their first form in 2026 reaches for useActionState instead of three useState calls and a useEffect. That's a better default.

Quick aside: if you're building UI-heavy apps and want to see how design patterns like glassmorphism components or the rest of the component library look in a React 19 context, the components at Empire UI are already written against modern hooks patterns — they'll work fine without any migration.

FAQ

Read next