0f746592d9
For a more detailed explanation of the algorithm, refer to the comments in ppr-navigations.ts. Below is a high-level overview. ### Step 1: Render the prefetched data immediately Immediately upon navigation, we construct a new Cache Node tree (i.e. copy-on-write) that represents the optimistic result of a navigation, using both the current Cache Node tree and data that was prefetched prior to navigation. At this point, we haven't yet received the navigation response from the server. It could send back something completely different from the tree that was prefetched — due to rewrites, default routes, parallel routes, etc. But in most cases, it will return the same tree that we prefetched, just with the dynamic holes filled in. So we optimistically assume this will happen, and accept that the real result could be arbitrarily different. We'll reuse anything that was already in the previous tree, since that's what the server does. New segments (ones that don't appear in the old tree) are assigned an unresolved promise. The data for these promises will be fulfilled later, when the navigation response is received. The tree can be rendered immediately after it is created. Any new trees that do not have prefetch data will suspend during rendering, until the dynamic data streams in. ### Step 2: Fill in the dynamic data as it streams in When the dynamic data is received from the server, we can start filling in the unresolved promises in the tree. All the pending promises that were spawned by the navigation will be resolved, either with dynamic data from the server, or `null` to indicate that the data is missing. A `null` value will trigger a lazy fetch during render, which will then patch up the tree using the same mechanism as the non-PPR implementation (serverPatchReducer). Usually, the server will respond with exactly the subset of data that we're waiting for — everything below the nearest shared layout. But technically, the server can return anything it wants. This does _not_ create a new tree; it modifies the existing one in place. Which means it must follow the Suspense rules of cache safety. ## To Do Not all necessarily PR-blocking, since the status quo is that navigations don't work at all when PPR is enabled - [x] Figure out how to handle dynamic metadata. Need to switch from prefetched metadata to final. - [x] Some mistake related to parallel routes, need to look into failing tests Closes NEXT-1894 |
||
|---|---|---|
| .. | ||
| compat | ||
| experimental/testmode | ||
| font | ||
| image-types | ||
| legacy | ||
| navigation-types/compat | ||
| src | ||
| types | ||
| amp.d.ts | ||
| amp.js | ||
| app.d.ts | ||
| app.js | ||
| babel.d.ts | ||
| babel.js | ||
| cache.d.ts | ||
| cache.js | ||
| client.d.ts | ||
| client.js | ||
| config.d.ts | ||
| config.js | ||
| constants.d.ts | ||
| constants.js | ||
| document.d.ts | ||
| document.js | ||
| dynamic.d.ts | ||
| dynamic.js | ||
| error.d.ts | ||
| error.js | ||
| head.d.ts | ||
| head.js | ||
| headers.d.ts | ||
| headers.js | ||
| image.d.ts | ||
| image.js | ||
| index.d.ts | ||
| jest.d.ts | ||
| jest.js | ||
| license.md | ||
| link.d.ts | ||
| link.js | ||
| navigation.d.ts | ||
| navigation.js | ||
| og.d.ts | ||
| og.js | ||
| package.json | ||
| README.md | ||
| router.d.ts | ||
| router.js | ||
| script.d.ts | ||
| script.js | ||
| server.d.ts | ||
| server.js | ||
| taskfile-ncc.js | ||
| taskfile-swc.js | ||
| taskfile-watch.js | ||
| taskfile-webpack.js | ||
| taskfile.js | ||
| tsconfig.json | ||
| web-vitals.d.ts | ||
| web-vitals.js | ||
| webpack.config.js | ||
Next.js
Getting Started
Visit https://nextjs.org/learn to get started with Next.js.
Documentation
Visit https://nextjs.org/docs to view the full documentation.
Who is using Next.js?
Next.js is used by the world's leading companies. Check out the Next.js Showcase to learn more.
Community
The Next.js community can be found on GitHub Discussions, where you can ask questions, voice ideas, and share your projects.
To chat with other community members you can join the Next.js Discord.
Our Code of Conduct applies to all Next.js community channels.
Contributing
Please see our contributing.md.
Good First Issues
We have a list of good first issues that contain bugs that have a relatively limited scope. This is a great place to get started, gain experience, and get familiar with our contribution process.
Authors
- Tim Neutkens (@timneutkens)
- Naoyuki Kanezawa (@nkzawa)
- Guillermo Rauch (@rauchg)
- Arunoda Susiripala (@arunoda)
- Tony Kovanen (@tonykovanen)
- Dan Zajdband (@impronunciable)
Security
If you believe you have found a security vulnerability in Next.js, we encourage you to responsibly disclose this and not open a public issue. We will investigate all legitimate reports. Email security@vercel.com to disclose any security vulnerabilities.