[use] Rework await vs use DeepDive to fix inaccurate framing#8521
Conversation
Size changesDetails📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
| ``` | ||
|
|
||
| Prefer `await` in a Server Component when possible, since it keeps the data fetching on the server. If a Server Component above already awaits the data, pass the resolved value down as a prop instead of creating a new Promise to call `use`. | ||
| Prefer `await` in a Server Component when possible. If a Server Component above already awaits the data, pass the resolved value down as a prop instead of creating a new Promise to call `use`. |
There was a problem hiding this comment.
Prefer
awaitin a Server Component when possible. If a Server Component above already awaits the data, pass the resolved value down as a prop instead of creating a new Promise to calluse.
This still feels a bit too strong to me. It sounds as if use is strictly worse but it's not. It's just that if you need the actual Promise on the server, you await where you need it, and if you need it on the client, you use that Promise instead.
There was a problem hiding this comment.
Pull request overview
This PR rewrites the “Should I resolve a Promise in a Server or Client Component?” DeepDive on the use reference page to clarify that await unwraps Promises in Server Components while use unwraps Promises in Client Components, and to frame “passing a Promise down” as a general Suspense technique rather than something specific to use.
Changes:
- Reframes the DeepDive to focus on where the Promise is unwrapped (server via
await, client viause). - Adds an example showing passing a Promise down and
awaiting it deeper within a<Suspense>boundary. - Updates the closing guidance to emphasize the real constraint: Client Components can’t
awaitduring render.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
Rewrites the "Should I resolve a Promise in a Server or Client Component?" DeepDive on the
usereference page.The previous text said to prefer
awaitin a Server Component "since it keeps the data fetching on the server". That's not accurate: when the Promise is created in a Server Component, the fetch runs on the server whether youawaitit or pass it down, passing an unawaited Promise streams the resolved value to the client, it doesn't move the fetch (raised by @samselikoff). The section also taught passing a Promise down as something specific touse, when the same technique works withawaitin a deeper Server Component.New framing (from discussion with @gaearon)
awaitunwraps a Promise on the server,useunwraps it on the client.usefeature. Wrapped in<Suspense>, only that part of the tree waits.await, pass down +awaitdeeper (unblocking on the server), pass down +usedeeper (unblocking on the client).awaitduring render, so they unwrap withuse. The popover/tooltip case stays attached to the client example.