React 19 Features

React 19 is the biggest release since hooks, but most of it follows from one idea: Actions. React 18 gave us transitions for rendering; React 19 extends them to async work. A function that does async work inside a transition is an Action, and React tracks its pending state, errors, optimistic updates and form resets for you. useActionState, useOptimistic, useFormStatus and <form action={fn}> are all built on that.

Alongside Actions came a set of "finally" fixes that remove boilerplate: ref is a plain prop (no more forwardRef), <Context> is its own provider, ref callbacks can return a cleanup, <title> and <meta> can live in any component, and Server Components became stable. And a clean-up of old APIs: ReactDOM.render, string refs, propTypes and defaultProps on functions are gone.

Mental model for interviews: React 18 was about when React renders (concurrency); React 19 is about how you mutate data (Actions) and removing old ceremony.

import { createContext, useContext, useRef } from "react";

const ThemeContext = createContext("light");

// React 19: ref is a normal prop on function components.
function TextInput({ label, ref }) {
  return <input aria-label={label} ref={ref} />;
}

function ThemedLabel() {
  const theme = useContext(ThemeContext);
  return <p>Theme: {theme}</p>;
}

export function Form({ log }) {
  const inputRef = useRef(null);
  return (
    // React 19: <ThemeContext> is the provider (was <ThemeContext.Provider>).
    <ThemeContext value="dark">
      <ThemedLabel />
      <TextInput label="Name" ref={inputRef} />
      <button onClick={() => inputRef.current.focus()}>Focus</button>
      <div
        ref={(node) => {
          log.push("ref attached");
          return () => log.push("ref cleanup"); // React 19: ref callbacks can return a cleanup
        }}
      />
    </ThemeContext>
  );
}

The headline list (React 19.0, December 5, 2024):

An Action is a function that performs an async side effect (save, delete, submit) and is run inside a transition. In React 18, startTransition only accepted synchronous functions. React 19 accepts async ones and keeps isPending true until the whole async function finishes. Because the work is a transition, the current UI stays responsive, and state updates made during the action are applied together at the end.

The problem it solves is the pending/error boilerplate everyone wrote for every button that talks to a server: setIsPending(true), try, await, setIsPending(false), catch, setError, and don't forget double submits. Mental model: an Action is a transaction wrapped around an async function. React opens it (pending), runs your code, and closes it (commits the result) when the promise settles.

import { useState, useTransition } from "react";

// React 18 and earlier: pending and error state by hand.
function UpdateNameOld() {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, setIsPending] = useState(false);

  async function handleSubmit() {
    setIsPending(true);
    const error = await updateName(name);
    setIsPending(false);
    if (error) {
      setError(error);
      return;
    }
    setError(null);
  }

  return (
    <div>
      <input aria-label="Name" value={name} onChange={(e) => setName(e.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>Update</button>
      {error && <p role="alert">{error}</p>}
    </div>
  );
}

// React 19: an async transition (an "Action") tracks pending for you.
function UpdateNameNew() {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  function handleSubmit() {
    startTransition(async () => {
      const error = await updateName(name);
      startTransition(() => {
        setError(error); // a state update after await: wrap it again
      });
    });
  }

  return (
    <div>
      <input aria-label="Name" value={name} onChange={(e) => setName(e.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>Update</button>
      {error && <p role="alert">{error}</p>}
    </div>
  );
}

Why it's a transition and not just "async with a flag":

• Non-blocking: state updates inside it are low priority, so typing elsewhere stays responsive.
• Batched: updates made during the Action are committed together when it finishes, so you don't see half-applied results.
• Composable: useOptimistic only works inside a transition (it shows a temporary value while the Action is pending), and <form action> runs your function as an Action automatically.

Naming convention from the React team: call functions that are used as Actions somethingAction (saveAction, deleteAction), and props that accept them action or xxxAction, so it's clear they'll run in a transition.

useActionState turns an Action into state: you give it an action function and an initial state; it gives you back the latest state, a wrapped action to call (or pass to a form), and isPending. Each time the action runs, its return value becomes the new state.

const [state, formAction, isPending] = useActionState(actionFn, initialState, permalink?);
// actionFn(previousState, payload) → nextState (sync or async)

Mental model: it's useReducer for async work. A reducer takes (state, action) and returns the next state; useActionState's function takes (previousState, payload) and returns (or resolves to) the next state, and it may have side effects, like a network request. The "payload" is whatever you pass when calling it; when it's a form's action, it's the form's FormData.

My notes called it "kinda similar to TanStack Query", and showed const { execute, pending, error } = useActionState(saveUserData). That API never existed (see the correction below). Here's the same form with the real API:

import { useActionState } from "react";

// The action: (previous state, form data) → next state. Errors are returned, not thrown.
async function saveUser(prevState, formData) {
  const userData = { name: formData.get("name"), email: formData.get("email") };
  const response = await fetch("/api/save-user", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(userData),
  });
  if (!response.ok) {
    return { ...prevState, error: `Save failed (HTTP ${response.status})` };
  }
  return { user: await response.json(), error: null };
}

export function UserForm() {
  const [state, formAction, isPending] = useActionState(saveUser, { user: null, error: null });

  return (
    <div>
      <form action={formAction}>
        <input name="name" aria-label="Name" defaultValue={state.user?.name ?? ""} />
        <input name="email" aria-label="Email" type="email" />
        <button type="submit" disabled={isPending}>
          {isPending ? "Saving..." : "Save"}
        </button>
      </form>
      {state.error && <div role="alert">Error: {state.error}</div>}
      {state.user && <p>Saved {state.user.name}</p>}
    </div>
  );
}

const [count, dispatch, isPending] = useActionState(async (prev, amount) => {
  await new Promise((r) => setTimeout(r, 10)); // pretend to save
  return prev + amount;
}, 0);

startTransition(() => {
  dispatch(1);
  dispatch(10);
  dispatch(100);
});
// action calls: prev=0 +1, prev=1 +10, prev=11 +100 → count is 111

When to use it: forms and buttons whose result you want to show (a success message, a validation error list, the saved record) and whose pending state drives the UI. It's especially natural with Server Functions in Next.js, where the action runs on the server and the optional permalink argument lets the form work before JavaScript loads (progressive enhancement). When not to: reading data (use a query library or use()), or complex cache updates across the app (TanStack Query's useMutation + invalidation).

React 19 lets you pass a function to <form action> (and to formAction on a <button> or <input type="submit">). On submit, React calls it with the form's FormData, runs it as an Action (a transition), and resets the form after it succeeds. No onSubmit, no event.preventDefault(), no controlled inputs needed for simple forms.

useFormStatus (from react-dom) lets a component inside a form read that form's submission status: { pending, data, method, action }. That's what lets a design-system <SubmitButton> disable itself and show a spinner without the form passing it props.

Mental model: the <form> is a provider and useFormStatus is its consumer, like context: it reports on the nearest parent <form>, and only that.

import { startTransition, useState } from "react";
import { useFormStatus } from "react-dom";

function SubmitButton() {
  const { pending, data } = useFormStatus(); // the status of the <form> this button is inside
  return (
    <button type="submit" disabled={pending}>
      {pending ? `Subscribing ${data.get("email")}…` : "Subscribe"}
    </button>
  );
}

export function Newsletter({ subscribe }) {
  const [message, setMessage] = useState("");

  async function subscribeAction(formData) {
    const email = formData.get("email");
    await subscribe(email);
    startTransition(() => setMessage(`Subscribed ${email}`)); // state update after await
  }

  return (
    <form action={subscribeAction}>
      <input name="email" aria-label="Email" />
      <SubmitButton />
      <p>{message}</p>
    </form>
  );
}

Things that are easy to miss:

• formAction on a button overrides the form's action for that button, so one form can have "Save" and "Save as draft" doing different things.
• Progressive enhancement: with a framework and a Server Function as the action, the form works as a normal HTML POST before hydration.
• Validation: native attributes (required, type="email") still run before the action. For richer rules use useActionState and return field errors, or React Hook Form (see Forms with React 19 actions).
• onSubmit still works and is still right when you need preventDefault logic or a library that expects it.
• 19.3 changes: onReset now fires when React auto-resets a form after a Server Action, submit events include the submitter, and form status no longer resets when component state is updated (from the 19.3 changelog).

useOptimistic shows a temporary value while an Action is pending, so the UI can reflect what the user did immediately ("Sending…" messages, a filled heart, an item in a list) instead of waiting for the server. When the Action finishes, the temporary value is thrown away automatically and the real state shows: the confirmed value on success, the original value on failure.

const [optimisticState, setOptimistic] = useOptimistic(actualState, reducer?);

Mental model: an overlay on top of your real state that exists only for the lifetime of the Action. You never "undo" it; it simply stops existing when the transition ends. Compare TanStack Query's version (see Optimistic updates), where you snapshot the cache and write the rollback yourself.

import { startTransition, useOptimistic, useState } from "react";

export function Thread({ send }) {
  const [messages, setMessages] = useState([{ id: 1, text: "Hi!" }]);
  const [error, setError] = useState(null);
  const [optimisticMessages, addOptimistic] = useOptimistic(
    messages,
    (current, text) => [...current, { id: `temp-${text}`, text, sending: true }],
  );

  async function sendAction(formData) {
    const text = formData.get("text");
    addOptimistic(text); // shows immediately, only while this action is pending
    try {
      const saved = await send(text);
      startTransition(() => {
        setMessages((prev) => [...prev, saved]);
        setError(null);
      });
    } catch {
      startTransition(() => setError(`Couldn't send "${text}"`));
    }
  }

  return (
    <>
      <ul>
        {optimisticMessages.map((m) => (
          <li key={m.id}>
            {m.text}
            {m.sending && <small> (sending…)</small>}
          </li>
        ))}
      </ul>
      {error && <p role="alert">{error}</p>}
      <form action={sendAction}>
        <input name="text" aria-label="Message" />
        <button type="submit">Send</button>
      </form>
    </>
  );
}

Where it fits: likes and bookmarks, chat messages, toggles, renaming, adding to a list: anything that almost always succeeds and where waiting feels sluggish. Pair it with useActionState when the server result is also state (setOptimistic then dispatchAction in the same transition). Avoid it where the server decides the outcome (payments, generated ids the next screen needs).

use is a React 19 API for reading a resource during render: a promise (suspends until it resolves) or a context (like useContext). It's called use, not useSomething, because it isn't a normal hook: it can be called conditionally, inside if blocks and loops and after early returns. It still has to be called during render, in a component or a hook.

Mental model: use(promise) is await for components. The component's code reads as if the value is already there; React handles the waiting with the nearest <Suspense> and errors with the nearest error boundary.

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

export const ThemeContext = createContext("light");

// use(context) may be called after an early return or inside a condition.
export function Heading({ children }) {
  if (children == null) return null;
  const theme = use(ThemeContext);
  return <h1 className={theme}>{children}</h1>;
}

// use(promise): the promise is created by the caller and passed down.
function Comments({ commentsPromise }) {
  const comments = use(commentsPromise);
  return <ul>{comments.map((c) => <li key={c.id}>{c.text}</li>)}</ul>;
}

export function Post({ commentsPromise }) {
  return (
    <article>
      <Heading>My post</Heading>
      <Suspense fallback={<p>Loading comments…</p>}>
        <Comments commentsPromise={commentsPromise} />
      </Suspense>
    </article>
  );
}

Rules and real messages from React 19.3:

• Don't create the promise during render. A new promise on every render never settles in time. In my tests the component either stayed on the fallback forever, refetching on every retry (see use() with Suspense for data), or, when React replayed the render with a different promise, logged: "A component was suspended by an uncached promise. Creating promises inside a Client Component or hook is not yet supported, except via a Suspense-compatible library or framework."
• Don't wrap it in try/catch. React logged "use was called from inside a try/catch block. This is not allowed and can lead to unexpected behavior. To handle errors triggered by use, wrap your component in a error boundary.", and the catch received React's internal "Suspense Exception: This is not a real error!…" object instead of real data. Use an error boundary, or promise.catch(() => fallbackValue) before passing it to use.
• Rejected promises throw to the nearest error boundary.
• 19.3 adds a development warning "when use is called incorrectly in a conditional" (react#37104, from the 19.3 changelog). The post doesn't say which pattern triggers it, and I didn't reproduce it.

Before React 19, <title> and <meta> were "outside" React: you set document.title in an effect or used react-helmet. React 19 lets any component render <title>, <meta> and <link>, and React hoists them into <head>, on the client and in server rendering alike. It also manages stylesheets (load order via precedence, deduplication, waiting for them before showing content that needs them), async scripts (deduplicated wherever they're rendered), and gives you functions to hint resource loading early.

Mental model: the component that knows what the page is (a blog post, a product) also declares what the <head> should contain, and React does the plumbing, like it does for the DOM in <body>.

import { preconnect, preload, prefetchDNS } from "react-dom";

export function BlogPost({ post }) {
  preconnect("https://cdn.example.com"); // we'll fetch from here soon
  prefetchDNS("https://analytics.example.com"); // we might
  preload("https://cdn.example.com/fonts/inter.woff2", { as: "font", type: "font/woff2", crossOrigin: "" });

  return (
    <article>
      <title>{`${post.title} | My Blog`}</title>
      <meta name="description" content={post.summary} />
      <link rel="canonical" href={`https://blog.example.com/${post.slug}`} />
      <h1>{post.title}</h1>
      <p>{post.summary}</p>
    </article>
  );
}

Stylesheets: give a <link rel="stylesheet"> a precedence and React treats it as a managed resource: it's moved into <head> (the test sees <link rel="stylesheet" href="/card.css" data-precedence="default">), inserted in precedence order, and only inserted once however many components render it. React also waits for it to load before revealing the content that depends on it (inside a Suspense boundary), to avoid a flash of unstyled content. jsdom doesn't load CSS, and in my test the content rendered without waiting, so I couldn't observe that part in the sandbox.

When to still use a library: route-level defaults and overrides (react-helmet, or your framework's metadata API such as Next.js's metadata export), which merge titles from nested routes. For a single component declaring its own page's title, React 19 is enough.

React 19 deleted APIs that had been deprecated for years. Interviews like this topic because codebases still contain the old forms, and an upgrade fails in specific ways. The overall direction: one way to do each thing: JavaScript defaults instead of defaultProps, TypeScript instead of propTypes, createRoot instead of render, ref objects/callbacks instead of strings, createContext instead of legacy context.

Each one, tested on React 19.3:

// 1. Legacy root APIs are gone from react-dom
ReactDOM.render; // undefined (also hydrate, unmountComponentAtNode, findDOMNode)

// 2. defaultProps on function components is ignored
function Old({ name }) { return <p>Hello {String(name)}</p>; }
Old.defaultProps = { name: "world" }; // renders "Hello undefined"
function New({ name = "world" }) { return <p>Hi {name}</p>; } // renders "Hi world"

// 3. propTypes are silently ignored (no warning for a wrong type)
Price.propTypes = { amount: PropTypes.number.isRequired };
<Price amount="not a number" />; // renders, console stays empty

// 4. String refs throw
class Legacy extends Component {
  render() { return <input ref="name" />; }
}
// Error: Expected ref to be a function, an object returned by React.createRef(), or undefined/null.

// 5. element.ref is deprecated; ref is in props now
const el = <div ref={fn} />;
el.ref; // logs "Accessing element.ref was removed in React 19. ref is now a regular prop. …"
el.props.ref; // fn

The rest of the list:

function Button({ label, size }) {
  return <button className={size}>{label}</button>;
}
Button.defaultProps = { size: "medium" };

<Button label="Save" />;

React now ships minor releases with real features rather than waiting for a major. Everything below is from the official release posts on react.dev (19.2 on October 1, 2025; 19.3 on September 9, 2026) and the React CHANGELOG (19.1.0 on March 28, 2025), checked against the installed react@19.3.0 and @types/react@19.3.0. I tested what can run in jsdom; things that need a real browser (View Transition animations, Trusted Types) or a server (partial pre-rendering, Server Components) are described, not run.

React 19.1 (March 2025)

• Owner Stacks and captureOwnerStack() (development only): a stack of which components rendered the current one, rather than the parent chain. The test calls it inside Leaf and gets at Middle … / at App …. Error overlays and logging tools use it.
• Suspense improvements: Suspense boundaries behave consistently on the client, the server and during hydration; hydration scheduling and retries were improved.
• useId format changed so ids are valid in CSS selectors (no more colons).
• Development warnings for null/undefined values created in effects, and act removed from production builds.

React 19.2 (October 2025)

• <Activity mode="visible" | "hidden">: hide part of the tree while keeping its state, cleaning up its effects and pre-rendering it at low priority (see Activity: hiding UI without losing state).
• useEffectEvent: a function called from an effect that always sees the latest props/state and isn't a dependency (see useEffectEvent).
• cacheSignal() (Server Components only): an AbortSignal that fires when a cache()d result is no longer needed, so you can abort its fetch.
• Performance Tracks in Chrome DevTools: a Scheduler track (what React works on at each priority) and a Components track.
• Partial pre-rendering in react-dom: prerender returns a static shell plus postponed state, and resume / resumeAndPrerender (and Node-stream versions) fill in the dynamic parts later.
• Batched Suspense reveals in streaming SSR, so server-streamed content appears in larger groups (it stops batching as page load nears the 2.5 s LCP threshold), and Web Streams APIs available in Node.
• eslint-plugin-react-hooks v6: flat config by default, plus React Compiler-powered rules.
• useId prefix is now _r_ (19.0 used :r:, 19.1 «r»), valid for view-transition-name and XML names. The test's first id is _r_0_, and it works in document.querySelector("#_r_0_"), which the old colon format didn't without escaping.

React 19.3 (September 2026)

• <ViewTransition> is stable: wrap content to animate it with the browser's View Transition API when it enters, exits, updates or moves between places (share). Only updates inside a Transition (startTransition, useDeferredValue, a Suspense reveal, an Action) animate; urgent updates don't. Animations are set with View Transition classes in CSS (enter, exit, update, share, default props) or the onEnter/onExit/onUpdate/onShare callbacks.
• addTransitionType(type): call it inside startTransition to say why a transition happened, so <ViewTransition enter={{ next: "from-right", previous: "from-left" }}> can animate differently. jsdom has no document.startViewTransition, so in the test the slide simply changed from "Slide 1" to "Slide 2" without animating. A browser without the API behaves the same way.
• Fragment refs are stable: <Fragment ref={ref}> gives a FragmentInstance that works on the fragment's children as a group, with no wrapper <div>: focus/focusLast/blur, addEventListener, observeUsing(observer) for Intersection/ResizeObservers, getClientRects, scrollIntoView and more. In the test, ref.current.focus() focused the first focusable child (the "Bold" button, skipping the <span>), and observeUsing observed each first-level child (Tools:, Bold, Italic).
• browser() from react-dom: use(browser()) makes a component render only in the browser. On the server it suspends, so the nearest Suspense fallback goes into the HTML; on the client it doesn't suspend (the test's component rendered straight away). It replaces the "set a mounted flag in an effect" and typeof window !== "undefined" patterns for things like local time zones or localStorage.
• Trusted Types: React passes TrustedHTML/TrustedScript/TrustedScriptURL objects through instead of turning them into strings, so sites enforcing require-trusted-types-for 'script' work.
• <Context> rendered directly in Server Components (imported from a 'use client' module), with no wrapper Provider component.
• From the changelog: Transitions render independently instead of being entangled into one render; effects are double-invoked in Strict Mode during hydration too; onFullscreenChange/onFullscreenError events; and fixes for useDeferredValue getting stuck, context in Suspense fallbacks, and several <Activity> and <ViewTransition> bugs.

import { Fragment, useLayoutEffect, useRef } from "react";

function Toolbar() {
  const ref = useRef(null);
  useLayoutEffect(() => {
    const observer = new IntersectionObserver(() => {});
    ref.current.observeUsing(observer); // observe every first-level child
    ref.current.focus(); // focus the first focusable child, depth-first
    return () => ref.current?.unobserveUsing(observer);
  }, []);
  return (
    <Fragment ref={ref}>
      <span>Tools:</span>
      <button>Bold</button>
      <button>Italic</button>
    </Fragment>
  );
}

Not covered here because I couldn't confirm it: anything announced for after 19.3 (the React Compiler 1.0, released October 2025, is a separate package and is covered in The React Compiler).