How React’s New ‘use’ Hook Simplifies Promise Handling in Server and Client Components

React recently introduced a hook called

use

for consuming Promises on the client. Unlike other hooks,

use

can be used inside conditional statements, blocks, and loops. In the future it may also consume Context, store, observable, etc.

On the server side, async/await is supported. The proposal is not a complete data‑fetching solution because it does not address caching; a separate

cache

API will be added later.

Example 1: Using await in Server Components

Server Components can use standard async/await to access promise‑based APIs without extra handling.

<code>// This example was adapted from the original Server Components RFC:
// https://github.com/reactjs/rfcs/pull/188
async function Note({id, isEditing}) {
  const note = await db.posts.get(id);
  return (
    <div>
      <h1>{note.title}</h1>
      <section>{note.body}</section>
      {isEditing ? <NoteEditor note={note} /> : null}
    </div>
  );
}
</code>

Hooks are generally restricted in async Server Components because they are stateless, but some hooks like useId can still be used.

Example 2: Using use in Client Components and Hooks

Client‑side rendered components cannot use await, so React provides the special

use

hook, which behaves like a React‑specific await. It can only be called inside React components or other hooks.

<code>// `use` inside of a React component or Hook...
const data = use(promise);

// ...roughly equates to `await` in an async function
const data = await promise;
</code>

use

is unique because it can be used inside conditionals, blocks, and loops, allowing data loading based on runtime conditions without extracting the logic into separate components.

<code>function Note({id, shouldIncludeAuthor}) {
  const note = use(fetchNote(id));

  let byline = null;
  if (shouldIncludeAuthor) {
    const author = use(fetchNoteAuthor(note.authorId));
    byline = <h2>{author.displayName}</h2>;
  }

  return (
    <div>
      <h1>{note.title}</h1>
      {byline}
      <section>{note.body}</section>
    </div>
  );
}
</code>

Future extensions may allow

use

to consume Context, stores, observables, etc.

<code>const resolvedValue = use(promise);
const contextualValue = use(Context);
const currentState = use(store);
const latestValue = use(observable);
</code>

Why introduce use ?

Seamless integration with the JavaScript ecosystem

The main motivation is to work naturally with the ubiquitous Promise API. Server Components originally struggled with promise‑based APIs, requiring extra boilerplate and error‑prone handling.

React prefers a single API for accessing data in Server, Client, and Shared Components.

Technical limits prevent async/await in Client Components, so

use

fills that gap.

Initially we aimed for a unified API across environments, but we later realized that supporting async/await in Server Components provides greater benefits.

Avoid a “uncanny valley” between server and client

Using different data‑access patterns makes it easier to track where code runs. Distinguishing Server and Client Components reduces confusion and helps developers understand the capabilities of each environment.

Async functions serve as a visual cue that a component is a Server Component.

Decouple data fetching from rendering

await

and

use

wrap asynchronous data without dictating how the data is fetched. Earlier Suspense APIs coupled fetching and rendering, requiring separate preload and read methods.

Standardizing a read‑async‑data primitive separates fetching from rendering, enabling patterns like non‑blocking prefetching.

<code>function TooltipContainer({showTooltip}) {
  const promise = fetchInfo();

  if (!showTooltip) {
    return null;
  } else {
    return <Tooltip content={use(promise)} />;
  }
}
</code>

Reduce complexity in React

The proposal aims to provide a shared primitive for data fetching that works across frameworks without imposing a rigid architecture, allowing frameworks like Next.js or Remix to adopt it without rewriting their routing or caching strategies.

Enable compile‑time optimizations

Because async/await is a language feature, compilers can optimize Server Components. Although

use

is not a syntax feature, it can be treated as such for linting and future compiler optimizations.