Suspense for Data

## The bug in one sentence Suspense is built on *retry*, and retry re-runs the component. A promise created inside the component body therefore cannot survive its own retry. ## Walking the loop ```jsx function Profile() { // new promise on every single render attempt const user = use(fetch('/api/user').then((r) => r.json())); return <h1>{user.name}</h1>; } ``` 1. React renders `Profile`. `fetch` fires request #1 and returns promise P1, still pending. 2. `use(P1)` suspends. React unwinds the subtree, shows the nearest fallback, and subscribes to P1. 3. P1 settles. React schedules a retry. 4. The retry calls the body again. `fetch` fires request #2 and returns a **different** promise, P2, pending. 5. `use(P2)` suspends. Go to 2. Nothing in that loop is broken code on React's side. React's contract is "if a render suspends on a pending promise, retry when it settles". Each retry honestly encounters a pending promise it has never seen. The identity of the resource is the thing the component failed to supply. A useful way to state the underlying rule: **the resource must be a function of the inputs, not of the render.** Two renders with the same props must produce the *same* promise object, not two equivalent ones. ## Why memoisation is not the fix The reflex answer is `useMemo(() => fetch(url).then(r => r.json()), [url])`. It is wrong for a specific reason: the render that computed the memo **never committed**, because it suspended. React is free to discard work from an abandoned render, and `useMemo` is documented as a performance hint rather than a semantic cache. Depending on it for correctness across a suspend is depending on unspecified behaviour. The same objection applies to `useRef` written during render, and `useState` initialisers are no better because the component instance's state is not established by a render that never mounted. ## What an actual fix looks like **Create the promise outside React.** A module-level cache keyed by request identity gives every render attempt the identical promise: ```js const cache = new Map(); export function fetchUser(id) { const key = `/api/user/${id}`; if (!cache.has(key)) { cache.set(key, fetch(key).then((r) => r.json())); } return cache.get(key); } ``` Now `use(fetchUser(id))` suspends on P1, retries, calls `fetchUser(id)` again, gets **P1 back already fulfilled**, reads the value synchronously, and the render completes. One request, one suspend, one retry. **Or hand the promise in from outside.** In a Server Components setup, the server starts the request and passes the promise down as a prop; the Client Component only reads it with `use`. The promise's identity then belongs to the parent render, not to the child's retry, so the loop cannot form. **Or use a data library.** Query libraries exist largely because that cache needs far more than a `Map`: keys, in-flight deduping, invalidation, garbage collection, and transfer of server-fetched data to the client. React deliberately does not ship one. ## Diagnosing it in the wild The signature is unmistakable once seen: a fallback that never clears, plus a network panel that grows without bound at roughly the latency of the endpoint. Related but distinct symptoms are worth separating — a fallback that never clears with *no* repeated requests usually means a promise that never settles; repeated requests *without* a stuck fallback usually means an effect with an unstable dependency, not Suspense at all. In development React 19 also warns explicitly that a component suspended on an uncached promise created during render, and points you at a framework or Suspense-compatible library. Treat that warning as the same bug caught early. ## The rule to carry away Inside a component you may **read** a resource, never **create** one. Creation happens above the component — in a parent, a module cache, or a library — where it can be keyed and reused. That single rule removes the entire class of Suspense refetch loops.