Understanding the Proposed React “use” Hook: Design, Usage, and Limitations

Background – React previously mentioned Suspense for data fetching , which was later removed, but libraries like useSwr and useQuery still implement similar ideas. The React team now proposes a new hook named use to improve data‑fetching support.

Introduction

Prerequisites – The use hook must be used together with Suspense , requiring a wrapper component that provides error boundaries and fallback UI.

function LoadingErrorWrapper({ children }) {
  return
}>
      {children}
}

Minimal example – A component can fetch data by passing a promise directly to use :

function Note({id}) {
  // This fetches a note asynchronously, but to the component author it looks like a synchronous operation.
  const note = use(fetchNote(id));
  return (
{note.title}
{note.body}
);
}

Unlike useSwr , the official version expects a Promise itself rather than a function returning a promise.

Promise caching – To mimic cache‑key behavior, developers can memoize the promise with useMemo so that a new promise is created only when its inputs change:

function Note({id}) {
  // return new promise when id changes
  const fetchNotePromise = useMemo(() => fetchNote(id), [id]);
  const note = use(fetchNotePromise);
  return (
{note.title}
{note.body}
);
}

The hook also allows calls inside control‑flow statements (if, switch, for), breaking the traditional Rules of Hooks and offering greater flexibility.

Design Motivation

Seamless support for the JavaScript ecosystem – By accepting a Promise directly, use avoids the extra IIFE needed in useEffect .

Distinguish client and server components – Server components should use async components, while client components can use the new use hook.

Encourage pre‑fetching and caching – Splitting promise creation from consumption enables early data fetching and improves user experience.

Higher‑level abstraction – Integrating data fetching into React reduces boilerplate but must be carefully designed to avoid excessive conventions.

Compile‑time optimizations – The proposal revisits compiler‑driven dependency analysis, though the final decision left it to ESLint plugins.

Limitations

The hook must be called inside a React component because it triggers re‑renders.

The surrounding function (the “parent”) must itself be a component or another hook; otherwise a compiler error occurs.

Specific Implementation – The hook attaches status , value , and reason fields to the supplied promise, then throws the promise for Suspense handling and uses a helper tryRerender() to schedule updates.

function use(promise) {
  if (promise.status === 'rejected') {
    // Handled by ErrorBoundary
    throw promise.reason;
  }
  if (promise.status === 'fulfilled') {
    // Normal return
    return promise.value;
  }
  promise.status = 'pending';
  // Throw promise; Suspense will catch it.
  throw promise.then(value => {
    promise.status = 'fulfilled';
    promise.value = value;
    tryRerender();
  }).catch(reason => {
    promise.status = 'rejected';
    promise.reason = reason;
  });
}

The hook’s ability to be called in control flow stems from its reliance on the fiber’s re‑render mechanism rather than attaching additional data to the fiber.

Controversy – The main debate centers on the hook’s name; the team chose the generic use to highlight its uniqueness while adhering to the “use‑” prefix convention.

About the Authors – The article is published by ByteDance’s Data Platform team, which provides data‑driven services internally and through the Volcano Engine brand.