No description
f9b85387fb
Before PPR, the way instant navigations work in Next.js is we prefetch
everything up to the first route segment that defines a loading.js
boundary. The rest of the tree is defered until the actual navigation.
It does not take into account whether the data is dynamic — even if the
tree is completely static, it will still defer everything inside the
loading boundary.
The approach with PPR is different — we prefetch as deeply as possible,
and only defer when dynamic data is accessed. If so, we only defer the
nearest parent Suspense boundary of the dynamic data access, regardless
of whether the boundary is defined by loading.js or a normal <Suspense>
component in userspace.
This PR removes the partial behavior of loading.js when the PPR flag is
enabled. In effect, loading.js now acts like a regular Suspense boundary
with no additional special behavior.
Note that in practice this usually means we'll end up prefetching more
than we were before PPR, which may or may not be considered a
performance regression by some apps. The plan is to address this before
General Availability of PPR by introducing granular per-segment
fetching, so we can reuse as much of the tree as possible during both
prefetches and dynamic navigations. But during the beta period, we
should be clear about this trade off in our communications.
## Testing strategy
While I was writing a test, I noticed that it's currently pretty
difficult to test all the scenarios that PPR is designed to handle, so I
gave special attention to setting up a testing strategy that I hope will
make this easier going forward. The overall pattern is based on how
we've been testing concurrent rendering features in the React repo for
many years:
- In the e2e test, spin up an HTTP server for responding to requests
sent by the test app. This simulates the data service that would be used
in a real Next.js application, whether it's direct db access, an ORM, or
a higher-level data access layer. The e2e test can observe when
individual requests are received, and control the timing of when the
data is fulfilled, without needing to mock any lower level I/O. (We're
already using a similar pattern to [test fetch
deduping](
|
||
|---|---|---|
| .cargo | ||
| .config | ||
| .devcontainer | ||
| .github | ||
| .husky | ||
| .vscode | ||
| bench | ||
| contributing | ||
| docs | ||
| errors | ||
| examples | ||
| packages | ||
| scripts | ||
| test | ||
| turbo/generators | ||
| .alexignore | ||
| .alexrc | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .gitattributes | ||
| .gitignore | ||
| .node-version | ||
| .npmrc | ||
| .prettierignore | ||
| .prettierignore_staged | ||
| .prettierrc.json | ||
| .rustfmt.toml | ||
| azure-pipelines.yml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| contributing.md | ||
| jest.config.js | ||
| jest.replay.config.js | ||
| lerna.json | ||
| license.md | ||
| lint-staged.config.js | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| readme.md | ||
| release.js | ||
| run-tests.js | ||
| rust-toolchain | ||
| socket.yaml | ||
| test-file.txt | ||
| tsconfig-tsec.json | ||
| tsconfig.json | ||
| tsec-exemptions.json | ||
| turbo.json | ||
| UPGRADING.md | ||
| vercel.json | ||
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.