React 19 Features: Complete Migration Guide from React 18
React 19 is the most significant update since hooks were introduced in React 16.8. Server Components become first-class citizens, Actions simplify data mutations, the new use() hook replaces complex data-fetching patterns, and the React Compiler eliminates most manual memoization. This guide covers every major feature with practical migration examples, concrete edge cases, and honest assessments of what works today versus what is still evolving.
Server Components: The Architecture Shift
Server Components run exclusively on the server and send rendered output to the client — zero JavaScript shipped for these components. This is fundamentally different from SSR, where components render on the server but then re-hydrate on the client. Because Server Components never hydrate, they can directly access databases, file systems, and backend services without standing up an API endpoint.
// Server Component (default in React 19)
// This component runs ONLY on the server
async function ProductPage({ productId }: { productId: string }) {
// Direct database access — no API needed
const product = await db.products.findUnique({
where: { id: productId },
include: { reviews: true, variants: true }
});
// Import a large library — it's never sent to the client
const { marked } = await import('marked');
const descriptionHtml = marked(product.description);
return (
<div>
<h1>{product.name}</h1>
<div dangerouslySetInnerHTML={{ __html: descriptionHtml }} />
<PriceDisplay price={product.price} />
{/* Client Component for interactivity */}
<AddToCartButton productId={product.id} />
{/* Server Component for reviews */}
<ReviewsList reviews={product.reviews} />
</div>
);
}
The Server/Client Boundary in Practice
The single concept that trips up most teams is the boundary itself. By default every component is a Server Component; you opt a subtree into the client with the 'use client' directive at the top of a file. Importantly, that directive is a one-way door — everything imported by a client module becomes part of the client bundle. Therefore, a common mistake is marking a high-level layout as a client component “just to use a single onClick,” which accidentally drags the entire tree onto the client and erases the benefit.
The practical pattern is to keep client components small and push them to the leaves, then pass server-rendered content into them as children. For instance, a client component can wrap a server component as a child without forcing that child to ship JavaScript:
'use client';
import { useState } from 'react';
// Client island — only the toggle logic ships to the browser
export function Collapsible({ title, children }: {
title: string;
children: React.ReactNode; // server-rendered content passes straight through
}) {
const [open, setOpen] = useState(false);
return (
<section>
<button onClick={() => setOpen(o => !o)}>{title}</button>
{open && children}
</section>
);
}
// Server Component composes them — ReviewsList never hydrates
function ProductReviews({ reviews }) {
return (
<Collapsible title="Reviews">
<ReviewsList reviews={reviews} />
</Collapsible>
);
}As a result, the interactive shell is tiny while the data-heavy list stays on the server. The other edge case worth memorizing: you cannot pass functions or class instances across the boundary as props, only serializable data. Consequently, event handlers must originate inside client components, and server-to-client communication for mutations flows through Actions instead.
React 19: Actions and Form Handling
Actions replace the patchwork of form libraries and manual fetch calls. They integrate with React’s transition system to provide pending states, error handling, and optimistic updates automatically. For everyday development, this is arguably the biggest quality-of-life improvement in the release.
'use client';
import { useActionState, useOptimistic } from 'react';
// Server Action
async function addToCart(prevState: CartState, formData: FormData) {
'use server';
const productId = formData.get('productId') as string;
const quantity = parseInt(formData.get('quantity') as string);
try {
const cart = await db.carts.addItem(productId, quantity);
return { success: true, cart, error: null };
} catch (error) {
return { success: false, cart: prevState.cart, error: error.message };
}
}
// Client Component using the action
function AddToCartForm({ productId, currentCart }) {
const [state, action, isPending] = useActionState(addToCart, {
success: false,
cart: currentCart,
error: null
});
const [optimisticCart, addOptimistic] = useOptimistic(
state.cart,
(current, newItem) => ({
...current,
items: [...current.items, { ...newItem, pending: true }]
})
);
return (
<form action={async (formData) => {
addOptimistic({ productId, quantity: 1 });
await action(formData);
}}>
<input type="hidden" name="productId" value={productId} />
<input type="number" name="quantity" defaultValue={1} min={1} />
<button type="submit" disabled={isPending}>
{isPending ? 'Adding...' : 'Add to Cart'}
</button>
{state.error && <p className="error">{state.error}</p>}
</form>
);
}Notably, because the form posts to a Server Action, the flow degrades gracefully: the form still submits even before client JavaScript loads, since the action is a real server endpoint. Meanwhile, useOptimistic renders the expected result immediately and React automatically reverts to the real state if the action throws. This is the kind of behavior teams previously hand-built with reducers and rollback logic.
The use() Hook: Simplified Data Fetching
The use() hook can unwrap promises and context values anywhere in your component, not just at the top level. This means you can read context or await data inside conditionals and loops — something earlier hooks forbade because of the rules of hooks.
import { use, Suspense } from 'react';
// use() with promises
function UserProfile({ userPromise }) {
const user = use(userPromise); // Suspends until resolved
return (
<div>
<h2>{user.name}</h2>
<p>{user.email}</p>
</div>
);
}
// use() with conditional context
function ThemeAwareButton({ useCustomTheme }) {
// This was impossible before — hooks couldn't be conditional
const theme = useCustomTheme ? use(CustomThemeContext) : use(DefaultThemeContext);
return <button style={{ background: theme.primary }}>Click</button>;
}
// Parent component provides the promise
function App() {
const userPromise = fetchUser(userId); // Start fetching immediately
return (
<Suspense fallback={<Skeleton />}>
<UserProfile userPromise={userPromise} />
</Suspense>
);
}One important edge case: you should not create the promise inside the component that calls use(), because each render would start a new fetch. Instead, create it in a parent (or, better, in a Server Component or a cache-aware framework loader) and pass it down. The docs recommend pairing use() with Suspense for loading states and an error boundary for rejections, since a rejected promise thrown by use() is caught by the nearest boundary just like any render error.
React Compiler: Automatic Memoization
The React Compiler (formerly “React Forget”) analyzes your components at build time and automatically inserts the equivalent of useMemo, useCallback, and memo where they help. As a result, you no longer hand-optimize re-renders for most components. In practice this removes a large share of optimization boilerplate and an entire category of stale-dependency bugs.
// Before React Compiler — manual optimization required
const MemoizedList = memo(function ProductList({ products, onSelect }) {
const sortedProducts = useMemo(
() => [...products].sort((a, b) => a.name.localeCompare(b.name)),
[products]
);
const handleSelect = useCallback(
(id) => onSelect(id),
[onSelect]
);
return sortedProducts.map(p =>
<ProductCard key={p.id} product={p} onSelect={handleSelect} />
);
});
// After React Compiler — just write normal code
function ProductList({ products, onSelect }) {
const sortedProducts = [...products].sort((a, b) => a.name.localeCompare(b.name));
return sortedProducts.map(p =>
<ProductCard key={p.id} product={p} onSelect={onSelect} />
);
}
// The compiler automatically optimizes this to be equivalentThat said, the compiler is not magic. It only optimizes components that follow the rules of React — pure render functions with no mutation of props or state during render. If a component breaks those rules, the compiler conservatively skips it rather than risk a behavior change, which is why teams run the bundled ESLint plugin to surface violations before relying on it. Note also that the corrected sort above copies the array first; mutating products in place was a latent bug in the original even with manual memoization.
Migration Strategy from React 18
Migrate incrementally — the new release is largely backward compatible with React 18 patterns. First, upgrade dependencies and resolve deprecation warnings. Then adopt new features one at a time: Actions first because they simplify the most code, then the Compiler for free performance, and finally Server Components, which require framework support such as Next.js or another React Server Components-capable bundler. Key deprecation notes worth flagging early: forwardRef is no longer required because ref is now a regular prop, useContext(Context) can be replaced with use(Context), the legacy string-ref API is removed, and propTypes and defaultProps on function components are gone in favor of TypeScript and default parameters.
When NOT to Adopt Everything: Trade-offs
It would be dishonest to present this release as a free win across the board. Server Components, in particular, impose a real architectural cost: they effectively require a framework and a Node-capable server or edge runtime, so a purely static site or a classic single-page app deployed to a CDN may gain little while taking on meaningful complexity. Furthermore, the mental model of the server/client boundary has a genuine learning curve, and debugging spans two runtimes. Similarly, while the Compiler is stable for many codebases, teams with heavy reliance on intentional mutation or non-idiomatic patterns should validate behavior carefully before removing existing memoization. As a balanced rule, adopt Actions and the Compiler broadly because they are low-risk and high-value, but treat a full Server Components migration as a deliberate architectural decision rather than a routine upgrade.
Key Takeaways
- Keep client components small and at the leaves; pass server-rendered content as
childrento avoid bloating the bundle - Prefer Actions with
useActionStateanduseOptimisticover hand-rolled fetch-and-rollback logic - Create promises for
use()in parents or loaders, never inside the consuming component, and wrap them in Suspense plus an error boundary - Lean on the React Compiler but run its ESLint plugin and keep render functions pure
- Adopt Actions and the Compiler first; treat Server Components as a deliberate architecture change
For further reading, refer to the MDN Web Docs and the web.dev best practices for comprehensive reference material.
React 19: Actions and Form Handling
Actions replace the patchwork of form libraries and manual fetch calls. They integrate with React’s transition system to provide pending states, error handling, and optimistic updates automatically. This is the biggest quality-of-life improvement for everyday React development.
'use client';
import { useActionState, useOptimistic } from 'react';
// Server Action
async function addToCart(prevState: CartState, formData: FormData) {
'use server';
const productId = formData.get('productId') as string;
const quantity = parseInt(formData.get('quantity') as string);
try {
const cart = await db.carts.addItem(productId, quantity);
return { success: true, cart, error: null };
} catch (error) {
return { success: false, cart: prevState.cart, error: error.message };
}
}
// Client Component using the action
function AddToCartForm({ productId, currentCart }) {
const [state, action, isPending] = useActionState(addToCart, {
success: false,
cart: currentCart,
error: null
});
const [optimisticCart, addOptimistic] = useOptimistic(
state.cart,
(current, newItem) => ({
...current,
items: [...current.items, { ...newItem, pending: true }]
})
);
return (
<form action={async (formData) => {
addOptimistic({ productId, quantity: 1 });
await action(formData);
}}>
<input type="hidden" name="productId" value={productId} />
<input type="number" name="quantity" defaultValue={1} min={1} />
<button type="submit" disabled={isPending}>
{isPending ? 'Adding...' : 'Add to Cart'}
</button>
{state.error && <p className="error">{state.error}</p>}
</form>
);
}The use() Hook: Simplified Data Fetching
The use() hook can unwrap promises and context values anywhere in your component, not just at the top level. This means you can conditionally read context or await data inside if statements and loops — something previous hooks couldn’t do.
import { use, Suspense } from 'react';
// use() with promises
function UserProfile({ userPromise }) {
const user = use(userPromise); // Suspends until resolved
return (
<div>
<h2>{user.name}</h2>
<p>{user.email}</p>
</div>
);
}
// use() with conditional context
function ThemeAwareButton({ useCustomTheme }) {
// This was impossible before — hooks couldn't be conditional
const theme = useCustomTheme ? use(CustomThemeContext) : use(DefaultThemeContext);
return <button style={{ background: theme.primary }}>Click</button>;
}
// Parent component provides the promise
function App() {
const userPromise = fetchUser(userId); // Start fetching immediately
return (
<Suspense fallback={<Skeleton />}>
<UserProfile userPromise={userPromise} />
</Suspense>
);
}React Compiler: Automatic Memoization
The React Compiler (formerly React Forget) analyzes your components at build time and automatically inserts useMemo, useCallback, and memo calls where needed. This means you no longer need to manually optimize re-renders — the compiler does it for you. In practice, this eliminates an entire category of performance bugs and removes 30-40% of optimization-related code.
// Before React Compiler — manual optimization required
const MemoizedList = memo(function ProductList({ products, onSelect }) {
const sortedProducts = useMemo(
() => products.sort((a, b) => a.name.localeCompare(b.name)),
[products]
);
const handleSelect = useCallback(
(id) => onSelect(id),
[onSelect]
);
return sortedProducts.map(p =>
<ProductCard key={p.id} product={p} onSelect={handleSelect} />
);
});
// After React Compiler — just write normal code
function ProductList({ products, onSelect }) {
const sortedProducts = products.sort((a, b) => a.name.localeCompare(b.name));
return sortedProducts.map(p =>
<ProductCard key={p.id} product={p} onSelect={onSelect} />
);
}
// The compiler automatically optimizes this to be equivalentMigration Strategy from React 18
Migrate incrementally — React 19 is backward compatible with React 18 patterns. Start by upgrading dependencies and fixing any deprecation warnings. Then adopt new features one at a time: Actions first (they simplify the most code), then the Compiler (free performance), then Server Components (requires framework support like Next.js 14+). Key deprecation notes: forwardRef is no longer needed (ref is a regular prop), useContext can be replaced with use(Context), and class component string refs are removed.
In conclusion, React 19 modernizes the framework with Server Components for zero-JS pages, Actions for simplified data mutations, use() for flexible data fetching, and the Compiler for automatic optimization. The migration path is smooth when taken incrementally — upgrade, fix deprecations, then adopt new features one layer at a time. By applying these patterns thoughtfully and respecting the trade-offs, you can build more robust, scalable, and maintainable applications while eliminating entire categories of boilerplate and performance issues.