React 19 use() Hook — Fix Infinite Suspension Loop

React has been the dominant UI library for nearly a decade, but one thing always felt clunky: async state. Every form submission, every server request, every loading state required you to manually juggle useState, useEffect, error boundaries, and disabled buttons. For something as common as 'user submits a form', the boilerplate was embarrassing. React 19 ships in 2024 as the most significant release since Hooks in 2016, and it's laser-focused on fixing exactly that.

The problem React 19 solves is the async data lifecycle. Before 19, you needed at minimum three useState calls (data, loading, error) just to handle a single server action — and that's before you even thought about optimistic updates or race conditions. The community built libraries like React Query and SWR specifically to paper over this gap. React 19 pulls the best ideas from those libraries directly into the framework.

By the end of this article you'll understand what React Actions are and why they replace the old pattern, how useActionState and useOptimistic dramatically reduce form-handling boilerplate, what the new use() hook unlocks for async resources, how the React Compiler eliminates the need to manually write useMemo and useCallback, and when to actually reach for each feature in a production codebase.

What React 19's use() Hook Actually Does

The use() hook is a new primitive in React 19 that reads the resolved value of a Promise or a Context directly inside render. Unlike useEffect or manual state wiring, use() suspends the component synchronously at the point of call — the component tree stops rendering until the Promise settles. This eliminates the need for wrapping async data fetches in custom hooks or conditional rendering patterns.

When you call use(promise), React treats it as a native suspense boundary: the component suspends, React discards the current render, and the nearest <Suspense> fallback shows. Once the Promise resolves, React retries the render with the resolved value. The key property: use() is not a hook — it does not follow the Rules of Hooks. You can call it inside loops, conditionals, and early returns. This makes it fundamentally different from useState or useEffect.

Use use() when you need to read async data directly in render — for example, fetching user profile data inside a server component or reading a context value that depends on a Promise. It shines in data-driven layouts where suspending the whole subtree is acceptable. Do not use it for side effects or event handlers; those still belong in useEffect or callbacks. The real power: it collapses the mental model of "fetch then render" into a single synchronous-looking call.

React Actions — Async State Without the Boilerplate

An Action in React 19 is any function that wraps an async operation and hands it off to React to manage. Think of it as React saying: 'Give me the async work — I'll track whether it's pending, catch your errors, and update state when it's done.'

Before Actions, a form submission looked like this: disable the button manually, set isLoading to true, call await fetch(), set the result, catch the error, set the error state, re-enable the button. Six steps for what should be one. With Actions you pass an async function directly to a form's action prop (or to useActionState), and React handles the pending/error lifecycle automatically.

The mental model shift is important. You stop thinking about loading states as things YOU manage, and start thinking about them as things React observes for you. The useFormStatus hook is a companion piece — it lets any child component inside a form read whether the parent form's action is currently pending, without prop drilling. This is how a Submit button can disable itself without the parent form needing to pass down an isLoading prop.

import { useActionState } from 'react';

// This is the Action — an async function React will manage for us.
// It receives the previous state and the FormData from the submission.
async function submitContactForm(previousState, formData) {
  const name = formData.get('name');
  const message = formData.get('message');

  // Simulate a real API call — could be fetch(), a server action, anything async
  const response = await fetch('/api/contact', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name, message }),
  });

  if (!response.ok) {
    // Returning an object with an error key is the convention for signaling failure
    return { error: 'Message failed to send. Please try again.' };
  }

  // Returning a success payload — this becomes the new `state` below
  return { success: true, message: `Thanks ${name}, we'll be in touch!` };
}

export default function ContactForm() {
  // useActionState wires up the action and gives us:
  //   state    — the current result (starts as null)
  //   dispatch — the function to call to trigger the action
  //   isPending — true while the async action is running
  const [state, dispatch, isPending] = useActionState(submitContactForm, null);

  return (
    // Pass dispatch as the form's action — React calls it on submit with FormData
    <form action={dispatch}>
      <label>
        Name
        <input name="name" type="text" required />
      </label>

      <label>
        Message
        <textarea name="message" required />
      </label>

      {/* Show error feedback from the action's return value */}
      {state?.error && (
        <p style={{ color: 'red' }}>{state.error}</p>
      )}

      {/* Show success feedback */}
      {state?.success && (
        <p style={{ color: 'green' }}>{state.message}</p>
      )}

      {/* isPending comes straight from React — no manual useState needed */}
      <button type="submit" disabled={isPending}>
        {isPending ? 'Sending...' : 'Send Message'}
      </button>
    </form>
  );
}

React 19 Actions API Quick Reference Table

React 19 consolidates several new APIs around the concept of Actions. Below is a quick reference table for the most commonly used functions, their purpose, and usage pattern.

The key distinction: useActionState is for managing state from an action's return, useFormStatus is for reading the action's pending status from any child, and useOptimistic is for giving the user instant feedback. Server Actions skip the client bundle entirely but can be called via <form action> or startTransition.

// Quick signatures for each API

// 1. useActionState
const [state, dispatch, isPending] = useActionState(
  async (prevState, formData) => {
    // ... handle submission
    return { success: true };
  },
  null
);

// 2. useFormStatus (in a child component)
function SubmitButton() {
  const { pending } = useFormStatus();
  return <button disabled={pending}>{pending ? 'Saving...' : 'Save'}</button>;
}

// 3. useOptimistic
const [optimisticCount, setOptimisticCount] = useOptimistic(
  realCount,
  (current, newVal) => current + 1
);

// 4. form action
<form action={dispatch}> // dispatch triggers the action with FormData

// 5. startTransition
import { startTransition } from 'react';
startTransition(async () => {
  const result = await serverAction();
  setState(result);
});

// 6. Server Action (in a file with "use server")
"use server";
export async function addToCart(productId) {
  // runs on server, receives serialized data
  await db.products.add(userId, productId);
}

useOptimistic — Show the Answer Before the Server Replies

useOptimistic solves a specific, painful UX problem: the gap between a user taking an action and the server confirming it. A like button that takes 400ms to respond feels broken. A todo item that doesn't appear until after a round-trip feels slow. Users in 2024 expect instant feedback.

The hook takes two arguments: the current real state, and an updater function that describes how to compute the optimistic version. When you call setOptimisticValue inside an async action, React immediately shows the optimistic UI. When the action resolves (or rejects), React automatically reverts to whatever the server sent back.

The key insight is that useOptimistic is scoped to the duration of an async transition. You don't manually clean it up. React handles rollback automatically if the server returns an error. This means you get the snappy feel of a local-first app without having to build a full offline-sync system.

import { useOptimistic, useState } from 'react';

// Simulated API call — imagine this is hitting your backend
async function toggleLikeOnServer(postId, currentlyLiked) {
  await new Promise(resolve => setTimeout(resolve, 600)); // Simulate latency

  // In a real app this would be: await fetch(`/api/posts/${postId}/like`, ...)
  // For demo purposes, we just return the toggled value
  return !currentlyLiked;
}

export default function LikeButton({ postId, initialLikeCount, initiallyLiked }) {
  // This is the REAL state — what the server has confirmed
  const [isLiked, setIsLiked] = useState(initiallyLiked);
  const [likeCount, setLikeCount] = useState(initialLikeCount);

  // useOptimistic takes: real value, and a function to compute the optimistic value
  // The second arg receives (currentState, optimisticValue) — the optimisticValue
  // is whatever you pass to setOptimisticLiked() below
  const [optimisticIsLiked, setOptimisticLiked] = useOptimistic(
    isLiked,
    (currentIsLiked, newLikedValue) => newLikedValue // Simply replace with the optimistic value
  );

  async function handleLikeToggle() {
    const nextLikedValue = !isLiked;

    // This IMMEDIATELY updates the UI — no waiting for the server
    setOptimisticLiked(nextLikedValue);

    // Also update the count optimistically in the UI
    setLikeCount(prev => nextLikedValue ? prev + 1 : prev - 1);

    try {
      // Now do the real work — React keeps the optimistic UI until this resolves
      const confirmedValue = await toggleLikeOnServer(postId, isLiked);

      // Commit the real server-confirmed value to state
      setIsLiked(confirmedValue);
    } catch (error) {
      // If the server call fails, React automatically reverts optimisticIsLiked
      // We also need to roll back our manual likeCount update
      setLikeCount(prev => nextLikedValue ? prev - 1 : prev + 1);
      console.error('Failed to update like status:', error);
    }
  }

  return (
    <button
      onClick={handleLikeToggle}
      aria-label={optimisticIsLiked ? 'Unlike post' : 'Like post'}
      style={{
        background: optimisticIsLiked ? '#e0245e' : '#ccc',
        color: 'white',
        border: 'none',
        padding: '8px 16px',
        borderRadius: '20px',
        cursor: 'pointer',
      }}
    >
      {/* Use the OPTIMISTIC value for instant visual feedback */}
      {optimisticIsLiked ? '❤️' : '🤍'} {likeCount}
    </button>
  );
}

The new use() Hook — Reading Resources Inline

use() is unlike any hook before it. It can be called conditionally (breaking the rules of hooks), it can be called inside loops, and it can unwrap both Promises and Context objects. It's React saying: 'I'll suspend this component for you while this promise resolves — no useEffect, no useState, no manual async lifecycle.'

For Context, use(MyContext) replaces useContext(MyContext) and works identically — except you can now call it inside an if-block, which lets you bail out of a context read early without restructuring your component.

For Promises, use() integrates with Suspense. You pass a promise directly to use(), and the component suspends (shows the nearest Suspense fallback) until the promise resolves. This is the client-side complement to React Server Components' async/await. The critical caveat: don't create the promise inside the render function — create it outside or via a cache/memo, or you'll create a new promise every render and suspend forever.

import { use, Suspense, createContext } from 'react';

// --- Context example: use() with conditional reads ---
const ThemeContext = createContext('light');

function ThemedBadge({ isAdmin }) {
  // This was IMPOSSIBLE with useContext — you couldn't call it conditionally
  // Now with use(), we can read context only when we actually need it
  if (!isAdmin) {
    return <span className="badge">Member</span>;
  }

  // Called conditionally — totally valid with use()
  const theme = use(ThemeContext);

  return (
    <span className={`badge badge--${theme} badge--admin`}>
      Admin
    </span>
  );
}

// --- Promise example: use() with Suspense ---

// IMPORTANT: Create the promise OUTSIDE the component.
// If you write `const userPromise = fetchUser()` inside UserCard,
// it creates a NEW promise every render → infinite suspension loop.
const userDataPromise = fetchUserFromAPI(42); // Created once, at module level

function UserCard() {
  // use() suspends this component until the promise resolves.
  // No useState, no useEffect, no loading check needed here.
  const user = use(userDataPromise);

  return (
    <div className="user-card">
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
}

// The parent wraps with Suspense to handle the loading state
export default function ProfilePage() {
  return (
    <ThemeContext.Provider value="dark">
      <ThemedBadge isAdmin={true} />

      {/* Suspense shows the fallback while UserCard's promise resolves */}
      <Suspense fallback={
        <div className="skeleton" aria-busy="true">Loading profile...</div>
      }>
        <UserCard />
      </Suspense>
    </ThemeContext.Provider>
  );
}

// Simulated fetch — in real life this is your API call
async function fetchUserFromAPI(userId) {
  const response = await fetch(`/api/users/${userId}`);
  if (!response.ok) throw new Error(`User ${userId} not found`);
  return response.json();
  // Returns: { id: 42, name: 'Sarah Chen', email: 'sarah@example.com' }
}

Ref as Prop vs forwardRef in React 19

One of the quality-of-life improvements in React 19 is that you can now pass ref as a regular prop to a function component without wrapping it in forwardRef. This eliminates a long-standing inconsistency where function components needed special treatment to receive refs, while class components did not.

Before React 19, if you wanted a parent component to access the DOM node of a child function component, you had to use forwardRef: ``jsx const Child = forwardRef((props, ref) => { return <input ref={ref} />; }); ` This added boilerplate and was confusing — many developers expected ref` to simply work as a prop.

In React 19, ref is treated just like any other prop. If you name a prop ref on a function component, React automatically forwards it to the underlying DOM element (or to the inner component). However, this only works if you explicitly accept ref as a prop. The old forwardRef API still works and is necessary for class components.

The key rule: if your component is a function component, you can simply accept ref as a prop. If it's a class component, you must still use forwardRef because class instances are not directly assignable to refs in the same way.

This change reduces code and makes component APIs more intuitive. It also aligns with the pattern of treating ref like key — a special prop that React handles.

// ─── BEFORE REACT 19 (still works in 19, but unnecessary) ───
import { forwardRef, useRef, useEffect } from 'react';

const OldStyledInput = forwardRef(function OldStyledInput(props, ref) {
  // forwardRef adds an extra layer of function signature
  return (
    <input
      ref={ref}
      style={{ border: '1px solid blue' }}
      {...props}
    />
  );
});

function OldParent() {
  const inputRef = useRef(null);
  useEffect(() => {
    if (inputRef.current) {
      inputRef.current.focus();
    }
  }, []);
  return <OldStyledInput ref={inputRef} placeholder="Old way" />;
}

// ─── IN REACT 19: ref as a regular prop ───
// No forwardRef needed! Just name a prop 'ref' and it works.
function NewStyledInput({ ref, ...props }) {
  return (
    <input
      ref={ref}
      style={{ border: '2px solid green' }}
      {...props}
    />
  );
}

function NewParent() {
  const inputRef = useRef(null);
  useEffect(() => {
    if (inputRef.current) {
      inputRef.current.focus();
    }
  }, []);
  return <NewStyledInput ref={inputRef} placeholder="New way" />;
}

// Both produce identical behavior: the parent obtains a ref to the input element.
// The new approach is clearer and closer to how developers expect refs to work.

// ⚠️ For class components, you still need forwardRef:
class ClassInput extends React.Component {
  render() {
    return <input ref={this.props.ref} />; // This alone does NOT forward
  }
}
// Must wrap: const ClassInputForwarded = forwardRef((props, ref) => <ClassInput {...props} ref={ref} />);

The React Compiler — Automatic Memoization Without the Mental Overhead

The React Compiler (previously 'React Forget') is an opt-in build-time tool that automatically inserts useMemo, useCallback, and React.memo optimizations into your code. You write plain, readable JavaScript — the compiler figures out what's referentially stable and what needs memoizing.

Why does this matter? Because manual memoization is one of the most error-prone parts of React development. Developers either over-memoize (wrapping everything in useMemo when it's unnecessary and making code harder to read) or under-memoize (missing the one place that's causing expensive re-renders). The compiler eliminates that entire class of bugs.

The compiler ships as a Babel/SWC plugin in React 19 and is already running on instagram.com in production. It works by analyzing your component's data dependencies at compile time. If a value genuinely can't change between renders given the same props/state, the compiler memoizes it automatically. If it can change, the compiler leaves it reactive. The result: you get the performance of a hand-optimized component with none of the cognitive overhead.

// BEFORE the React Compiler — what you had to write manually
import { useMemo, useCallback, memo } from 'react';

const ProductCard = memo(function ProductCard({ product, onAddToCart }) {
  // memo() prevents re-renders when parent re-renders but props haven't changed
  return (
    <div className="product-card">
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <button onClick={() => onAddToCart(product.id)}>Add to Cart</button>
    </div>
  );
});

function ProductListBefore({ products, taxRate, userId }) {
  // useMemo to avoid recalculating prices on every render
  const productsWithTax = useMemo(() => {
    return products.map(p => ({
      ...p,
      price: (p.basePrice * (1 + taxRate)).toFixed(2),
    }));
  }, [products, taxRate]); // Easy to forget a dependency here

  // useCallback to keep the function reference stable for memo(ProductCard)
  const handleAddToCart = useCallback((productId) => {
    fetch(`/api/cart/${userId}/add`, {
      method: 'POST',
      body: JSON.stringify({ productId }),
    });
  }, [userId]); // If you forget userId here, you get a stale closure bug

  return productsWithTax.map(product => (
    <ProductCard key={product.id} product={product} onAddToCart={handleAddToCart} />
  ));
}

// ─────────────────────────────────────────────────────
// AFTER the React Compiler — what you write instead
// The compiler transforms this into the equivalent of the code above
import { useState } from 'react';

function ProductCard({ product, onAddToCart }) {
  // No memo() wrapper needed — compiler handles it
  return (
    <div className="product-card">
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <button onClick={() => onAddToCart(product.id)}>Add to Cart</button>
    </div>
  );
}

function ProductListAfter({ products, taxRate, userId }) {
  // No useMemo — compiler sees taxRate and products are dependencies
  // and automatically memoizes this calculation
  const productsWithTax = products.map(p => ({
    ...p,
    price: (p.basePrice * (1 + taxRate)).toFixed(2),
  }));

  // No useCallback — compiler tracks that userId is the only dependency
  // and keeps the function reference stable automatically
  function handleAddToCart(productId) {
    fetch(`/api/cart/${userId}/add`, {
      method: 'POST',
      body: JSON.stringify({ productId }),
    });
  }

  return productsWithTax.map(product => (
    <ProductCard key={product.id} product={product} onAddToCart={handleAddToCart} />
  ));
}

// Both versions produce the SAME runtime behavior and performance.
// The compiler version is just dramatically easier to read and maintain.

useFormStatus — Prop Drilling No More

useFormStatus is a companion to Actions that solves a long-standing pain point: reading a form's pending state inside a deeply nested child component without prop drilling. Before, if you had a Submit button nested inside a complex form with multiple field components, you'd have to pass an isLoading prop all the way down. useFormStatus lets any component inside a <form> read the form's pending status directly.

The hook returns { pending, data, method, action }. The pending flag is true when the closest ancestor <form>'s action is running. This is especially powerful with design systems where you want a reusable SubmitButton component that disables itself automatically based on the form's state — no prop drilling, no context wrappers.

Critically, useFormStatus only works inside a <form> that uses React Actions via the action prop. If you're handling submissions manually with onSubmit, the hook won't see any pending state.

import { useFormStatus } from 'react-dom';

export default function SubmitButton({ children }) {
  // This works because the button is inside a <form> with action={dispatch}
  const { pending } = useFormStatus();

  return (
    <button type="submit" disabled={pending}>
      {pending ? 'Submitting...' : children}
    </button>
  );
}

// Usage in a parent form:
// <form action={dispatch}>
//   <input name="email" />
//   <SubmitButton>Send</SubmitButton>
// </form>

Server Components vs Client Components in React 19

React 19 formalizes the distinction between Server Components and Client Components through the 'use client' and 'use server' directives. Understanding when to use each is critical for performance and correct behavior.

Server Components run exclusively on the server during rendering. They can directly access databases, file systems, and backend APIs without exposing that logic to the client. They cannot use state, effects, or browser APIs. They produce serializable output that is sent as HTML or streaming chunks to the client. Server Components reduce bundle size because their code never reaches the browser.

Client Components are the traditional React components that run in the browser. They have full access to hooks (useState, useEffect, etc.), event handlers, and browser APIs. In React 19, any component tree that doesn't start with 'use client' is assumed to be a server component. To make a component a client component, add 'use client' as the first line of the file.

The key rule: you can import a Server Component inside a Client Component, but the Server Component will only render its initial output on the server; any dynamic behavior must be handled by the parent Client Component. Conversely, a Server Component can import both server and client components, but the client components will still execute on the client.

React 19 introduces Server Actions as well — functions marked with 'use server' that can be called from client components. They run on the server and can be used for mutations without building a separate API endpoint.

// ─── Server Component (no directive) ───
// This file runs on the server only.
// It can directly query a database.
import { getPosts } from '@/lib/db';
import LikeButton from './LikeButton'; // client component

export default async function PostList() {
  const posts = await getPosts(); // direct DB access
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
          <LikeButton postId={post.id} /> {/* client component with interactivity */}
        </li>
      ))}
    </ul>
  );
}

// ─── Client Component (with 'use client') ───
// This file runs in the browser.
'use client';

import { useState } from 'react';

export default function LikeButton({ postId }) {
  const [liked, setLiked] = useState(false);
  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? '❤️' : '🤍'}
    </button>
  );
}

// ─── Server Action (in a file with 'use server') ───
'use server';

export async function addLike(postId) {
  // runs on server, can directly mutate DB
  const db = await connect();
  await db.likes.insert({ postId, timestamp: new Date() });
}

Actions and Form Utilities — The Death of Form Libraries?

Forms are the last place you want boilerplate. Yet every React project ends up with a form library that's more complex than the form itself. React 19 finally fixes this by baking form handling into the framework itself.

The action prop on <form> is not a trick. It's a fundamental shift. Pass an async function directly to <form action={handler}> and React manages the pending state, error handling, and reset automatically. No onSubmit, no preventDefault, no useState for loading flags.

Why does this matter? Because form libraries like Formik and React Hook Form exist primarily to solve problems React created: manual state management for form fields, manual error handling, manual submission lifecycles. React 19 eliminates the root cause.

Server actions take this further. When the action is a function marked 'use server', React serializes the FormData, sends it to the server endpoint, and returns the result through useActionState. The data never touches a client-side reducer.

// io.thecodeforge — javascript tutorial

'use server';

export async function addUser(previousState, formData) {
  const name = formData.get('name');
  const email = formData.get('email');

  const response = await fetch('https://api.example.com/users', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name, email }),
  });

  if (!response.ok) {
    return { error: 'Failed to create user' };
  }

  return { success: true, user: await response.json() };
}

// App.jsx
'use client';
import { useActionState } from 'react';
import { addUser } from './actions';

export default function App() {
  const [state, formAction, isPending] = useActionState(addUser, null);
  
  return (
    <form action={formAction}>
      <input name="name" required />
      <input name="email" type="email" required />
      <button type="submit" disabled={isPending}>
        {isPending ? 'Saving...' : 'Add User'}
      </button>
      {state?.error && <p className="error">{state.error}</p>}
    </form>
  );
}

useTransition — The Concurrency Escape Hatch You've Been Ignoring

JavaScript is single-threaded. Forms freeze when you call setState inside a fetch callback. The screen goes dead until the state update finishes. Users hate this.

useTransition is React 19's answer to you maintaining perceived performance. It marks a state update as 'non-urgent' — React can pause it, yield to more important renders (like input changes or animations), then resume the transition later.

The killer use case? Form submissions with server actions. Wrap the submission in startTransition and the UI stays responsive even when the server takes 3 seconds to respond. The isPending flag gives you a cheap loading indicator without blocking the user from typing in other fields.

Here's the counterintuitive part: useTransition does not speed up your API calls. It speeds up the perception of your app by not sacrificing input latency for result rendering. Users can't tell the difference between a 200ms render and a 50ms render. They can tell when their keystrokes get swallowed.

// io.thecodeforge — javascript tutorial

import { useState, useTransition } from 'react';

export default function SearchForm() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  async function handleSubmit(formData) {
    const q = formData.get('search');
    setQuery(q);

    startTransition(async () => {
      const res = await fetch(`/api/search?q=${q}`);
      const data = await res.json();
      setResults(data);
    });
  }

  return (
    <form action={handleSubmit}>
      <input name="search" placeholder="Search..." />
      <button type="submit" disabled={isPending}>
        {isPending ? 'Searching...' : 'Search'}
      </button>
      {isPending && <Spinner />}
      <ul>
        {results.map(item => <li key={item.id}>{item.name}</li>)}
      </ul>
    </form>
  );
}

Diffs for Hydration Errors

React 19 overhauls hydration error messages. Previously, mismatches between server and client HTML produced cryptic stack traces. Now, React shows a diff — the exact line where the server HTML and client output diverge. This works because React 19 tracks the virtual DOM tree during hydration and compares it to the pre-rendered markup character by character. When a mismatch occurs, the error logs the expected versus actual HTML snippet with a caret pointer. This eliminates guesswork when debugging SSR failures, especially in third-party libraries that inject dynamic content. The diff also highlights missing or extra whitespace, which often causes silent hydration bugs. This feature reduces debug time from hours to minutes for teams migrating to Server Components.

// io.thecodeforge — javascript tutorial

// Before React 19: opaque error
ReactDOM.hydrateRoot(
  document.getElementById('root'),
  <App />
);
// After React 19: shows exact diff
// "Hydration failed: expected '<nav>' but got '<div>'"
//   line 12 col 3
//   server: ... <nav>...</nav> ...
//   client: ... <div>...</div> ...

Deprecations in React 19

React 19 officially deprecates several legacy APIs to streamline the library. The biggest change: forwardRef is deprecated. Passing ref as a prop works natively now — no need for the wrapper function. Also deprecated: defaultProps on function components. Use ES6 default parameters instead. The string ref API (deprecated since React 16) is finally removed. ReactDOM.render() is replaced by createRoot(). The old contextTypes and childContextTypes for class components are gone — use React.createContext exclusively. These removals reduce bundle size by roughly 5KB and eliminate confusing patterns. The React team provides codemods in the v19 upgrade guide to automate migration. Ignoring these deprecations triggers runtime warnings in development and will break in React 20.

// io.thecodeforge — javascript tutorial

// DEPRECATED: forwardRef
const Old = forwardRef((props, ref) => (
  <div ref={ref}>Old</div>
));

// React 19: ref as prop
const New = ({ ref, ...props }) => (
  <div ref={ref}>New</div>
);

// DEPRECATED: defaultProps
Old.defaultProps = { color: 'red' };

// React 19: ES6 defaults
const New = ({ color = 'red' }) => <div>{color}</div>;

Key Enhancements: Improved Developer Tools & TypeScript Support

React 19 introduces critical enhancements to developer tools and TypeScript support. The React Developer Tools extension now offers deeper component introspection, including real-time state snapshots for Server Components and improved profiling for concurrent features like useTransition. Error boundaries are better visualized, and hydration mismatches are highlighted directly in the component tree. For TypeScript, React 19 ships native type definitions that eliminate the need for @types/react. The new use() hook is fully typed, and generic refs now infer correctly without manual annotations. Server Components are properly typed as async components, and actions receive precise signatures. These changes reduce boilerplate, catch more compile-time errors, and streamline debugging, especially for large codebases migrating to concurrent rendering. The deprecation of React.FC in favor of explicit children types further aligns React with modern TypeScript patterns, making type safety a first-class concern without sacrificing developer experience.

// io.thecodeforge — javascript tutorial
// Improved TypeScript support in React 19
import { use, useState } from 'react';

async function fetchUser(id: string): Promise<{ name: string }> {
  return { name: 'Alice' };
}

function User({ id }: { id: string }) {
  const user = use(fetchUser(id)); // Fully typed without type assertion
  return <div>{user.name}</div>;
}

// Generic ref now infers correctly
function Input() {
  const ref = useState<HTMLInputElement | null>(null);
  return <input ref={ref} />; // No 'forwardRef' needed
}

The New use() Hook: A Game Changer

React 19's use() hook fundamentally changes how components handle asynchronous data. Unlike useEffect or Suspense, use() reads a promise or context synchronously within render, integrating directly into React's data flow. When given a promise, use() triggers Suspense boundaries seamlessly, eliminating manual loading states. For context, use(Context) replaces useContext, offering the same API but with built-in support for fallback during propagation. This hook is especially transformative for Server Components, where use() can await fetched data without breaking the component tree. It also works with custom data sources, as long as they implement a then-like interface. By reducing boilerplate and simplifying error boundaries, use() makes data fetching feel like a natural part of rendering. However, it cannot be used conditionally—React enforces the same rules as other hooks. This constraint ensures predictable behavior, especially when combined with concurrent features.

// io.thecodeforge — javascript tutorial
// The new use() hook in React 19
import { use, Suspense } from 'react';

function fetchMessage(): Promise<string> {
  return new Promise(resolve => setTimeout(() => resolve('Hello!'), 1000));
}

function Message() {
  const text = use(fetchMessage()); // Suspends automatically
  return <p>{text}</p>;
}

export default function App() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <Message />
    </Suspense>
  );
}