A React 19 client component calls `const user = use(fetch('/api/user/' + id).then(r => r.json()))` directly in its render body. It fetches endlessly and React logs a warning about an uncached promise. Explain the mechanism and how you would supply the promise instead.

## The loop, step by step ```jsx function User({ id }) { const user = use(fetch('/api/user/' + id).then((r) => r.json())); // broken return <p>{user.name}</p>; } ``` 1. React renders `User`. The render body calls `fetch`, producing promise **A** (pending) and firing request #1. 2. `use(A)` sees pending, so React suspends the component and shows the nearest Suspense fallback. 3. Promise **A** fulfills. React retries the render. 4. The render body runs from the top again — and `fetch` is called again, producing promise **B**, a different object, also pending, firing request #2. 5. `use(B)` sees pending. Suspend again. Go to step 3. Nothing ever completes, and the network tab fills with identical requests. React detects the shape of this problem and warns that a component suspended on a promise it has no way to cache. ## Why React cannot rescue you here For `use(promise)` to converge, the *same promise object* must be handed back on the retry render, so that by then it is already fulfilled and `use` can return its value. React identifies a resource by object identity, not by the URL or the arguments that produced it — it has no idea that promise A and promise B represent the same request. And it deliberately does not cache promises created during a client render: doing so would mean inventing a cache key out of the call site and the surrounding data, which is precisely the job of a data layer. So the invariant to internalise is: **`use` is a reader, and the caller owns the cache.** ## The supported ways to supply the promise **Pass it down from the server.** Start the request in a Server Component and hand the un-awaited promise to a client component as a prop. The server component runs once, so the promise is created once; React streams the eventual value to the client, where `use` unwraps it. ```jsx // server component function Page({ id }) { const userPromise = loadUser(id); // not awaited return ( <Suspense fallback={<p>Loading…</p>}> <User userPromise={userPromise} /> </Suspense> ); } ``` **Cache it by key on the client.** Keep a `Map` from key to promise outside the component, so the same `id` always yields the same object across renders: ```js const cache = new Map(); function getUser(id) { if (!cache.has(id)) cache.set(id, fetch('/api/user/' + id).then((r) => r.json())); return cache.get(id); } ``` This converges, but a hand-rolled `Map` never invalidates and is shared across users on the server, so it is a demo-grade solution rather than a production one. **Let a caching data layer own it.** A library or framework that already deduplicates and caches requests per key can return a stable promise for a given key; that is the boundary where retries, invalidation and staleness belong. On the server specifically, React's `cache()` memoizes a function's result for the duration of a request pass — useful for deduplicating the same lookup across several Server Components — but it is a Server-Component-only API and does not solve the client-render case. ## Why useMemo is not the fix Candidates reach for `useMemo(() => fetch(url), [url])`. It usually appears to work and is still wrong in principle: React treats a memo cache as a performance hint it is allowed to discard, so nothing guarantees the same promise across renders. It also does not survive remounts, and it hides the ownership question — the component still pretends to own a request it has no way to cancel, dedupe, or invalidate. ## The review heuristic When you see `use(` in a diff, look at the argument. If the expression that produces the promise is written inline in the render body, that is the bug, whatever the surrounding code looks like. A correct call site reads a promise that was already handed to it — a prop, a cached lookup, or something a data layer returned.