Every React developer has written this code:

const [data, setData] = useState<User | null>(null);
const [isLoading, setIsLoading] = useState(true);
const [error, setError] = useState<Error | null>(null);

useEffect(() => {
  let cancelled = false;
  setIsLoading(true);

  fetchUser(id)
    .then((user) => {
      if (!cancelled) setData(user);
    })
    .catch((err) => {
      if (!cancelled) setError(err);
    })
    .finally(() => {
      if (!cancelled) setIsLoading(false);
    });

  return () => {
    cancelled = true;
  };
}, [id]);

Three state variables. A cleanup flag. A dependency array. A race condition you have to think about every single time. And this is the correct version: most codebases skip the canceled flag and the error handling entirely.

This pattern is not wrong. It works. But it is boilerplate that exists because React had no built-in way to say "wait for this promise, then render." Every component that etches data had to reinvent the same loading/error/data state machine from scratch.

React 19 introduced use() to fix this. It is the first hook that can be called inside conditionals and loops, it integrates directly with Suspense, and it turns the fetch-then-setState pattern into a single line.

**What use() Does

use() reads a value from a resource at render time. The resource can be a Promise or a Context.

import { use } from "react";

// Read a promise - suspends until resolved
const user = use(userPromise);

// Read context - like useContext, but callable in conditionals
const theme = use(ThemeContext);

That is the entire API. One function, two use cases.

When you pass a Promise, use() integrates with the nearest <Suspense> boundary. While the promise is pending, the component suspends. React shows the Suspense fallback. When it resolves, React re-renders with the resolved value. When it rejects, the nearest Error Boundary catches the error.

No useState. No useEffect. No isLoading. No setData. React handles all of it.

use() does not fetch data. It unwraps a promise that someone else created. The distinction matters.

**The Pattern It Replaces
Wrap the snippet from above into a component and add the obligatory loading/error guards:

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    /* ... fetch, cancelled flag, setState ... */
  }, [userId]);

  if (isLoading) return <Skeleton />;
  if (error) return <ErrorMessage error={error} />;
  if (!user) return null;

  return <ProfileCard user={user} />;
}

Three state declarations, one effect, three conditional returns: all before you reach the actual UI. Every component that fetches data repeats this structure.

Here is the same component with use():

// Client Component - only the happy path
"use client";

import { use } from "react";

function UserProfile({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise);
  return <ProfileCard user={user} />;
}

// Server Component - creates the promise and defines the boundaries
import { Suspense } from "react";
import { ErrorBoundary } from "react-error-boundary";

export default function UserPage({ params }: { params: { id: string } }) {
  const userPromise = fetchUser(params.id);

  return (
    <ErrorBoundary fallback={<ErrorMessage />}>
      <Suspense fallback={<Skeleton />}>
        <UserProfile userPromise={userPromise} />
      </Suspense>
    </ErrorBoundary>
  );
}

The loading state is handled by <Suspense>. The error state is handled by <ErrorBoundary> (from the react-error-boundarypackage). The component itself only contains the happy path - the code that runs when data is available. The state machine has been moved from your code into React's runtime.

Because UserPage is a Server Component, it does not re-render. The promise reference is created once and passed down as a stable prop, no caching gymnastics needed.

**Separation of Concerns
Notice how the component that uses the data (UserProfile) is separated from the component that initiates the fetch and defines the loading/error UI (UserPage). This is intentional. The consumer doesn't know where the promise came from or what to show while waiting.