When PPR is enabled, the CacheNodeSeedData and FlightRouterState
contained in an RSC payload (whether it's static or dynamic) should
always have the same tree structure.
The only reason the two trees would ever be different is if the server
partially renders with `loading.tsx`, but that behavior doesn't exist
when PPR is enabled. (In that case, the CacheNodeSeedData would describe
only a subset of FlightRouterState.)
The behavior is already correct but to make the types a bit closer, this
changes the `parallelRoutes` slot of CacheNodeSeedData to be
non-nullable; if there are no children, it should be an empty object.
It's not semantically important, I'm only changing it to make the types
more consistent, since we typically traverse both trees in parallel.
Eventually we will probably merge these into a single transport type.
Closes NEXT-1868
The PPR implementation of navigateReducer is expected to diverge
significantly from the existing, non-PPR implementation. So this forks
them into two separate functions. This will be easier to maintain than
two different implementations inside the same function, especially
considering we don't expect any more changes to the non-PPR
implementation.
This also reduces the chances we'll introduce an accidental regression
into the non-PPR version, which is the stable one that all users (except
for the ones dogfooding PPR) are currently using.
For now, the two implementations are identical. I'll start making
changes in subsequent PRs.
Only one implementation will be included in the final build; the other
one will be dead code eliminated because the feature check is statically
inlined at build time:
```js
export const navigateReducer = process.env.__NEXT_PPR
? navigateReducer_PPR
: navigateReducer_noPPR
```
Closes NEXT-1856
Found this from build error trace while testing the change in #59569
```
docs/02-app/01-building-your-application/08-testing/02-jest.mdx": UnexpectedMDXError: Error: Build failed with 1 error:
--
_mdx_bundler_entry_point-776983b1-6900-47c0-98cc-0c35882e9532.mdx:297:0: ERROR: [plugin: @mdx-js/esbuild] Unexpected closing tag `</PageOnly>`, expected corresponding closing tag for `<PagesOnly>
```
Closes NEXT-1863
This PR updates the testing guides to use App Router and TypeScript,
also updates `/examples` to show `app` and `pages` examples.
## Overview
- [x] Create a new "Testing" section that is shared between `app` and
`pages`.
- [x] Explain the differences between E2E, unit testing, component
testing, etc.
- [x] Recommend E2E for `async` components as currently none of the
tools support it.
- [x] Update setup guides for **Cypress**, **Playwright**, and **Jest**
with latest config options, and examples for `app` and `pages`.
- [x] Add new guide for **Vitest**
- [x] Clean up `/examples`: use TS, show `app` and `pages` examples,
match docs config
## Cypress
- [x] E2E Tests
- [x] Component Testing
- [x] Client Components
- [x] Server Components
- [ ] `async` components
**Blockers:**
- TS: `Option 'bundler' can only be used when 'module' is set to
'es2015' or later`. In **tsconfig.json** compilerOptions, Next.js uses
"moduleResolution": "bundler", changing it to "node" fixes the issue but
it can have repercussions.
- https://github.com/cypress-io/cypress/issues/27731
- Version 14 is currently not supported for component testing
- https://github.com/cypress-io/cypress/issues/28185
## Playwright
- [x] E2E Tests
## Jest
- [x] Unit Testing
- [x] Client Components
- [x] Server Components
- [ ] `async` components:
https://github.com/testing-library/react-testing-library/issues/1209
- [x] 'server-only': https://github.com/vercel/next.js/pull/54891
- [x] Snapshot Testing
**Blockers:**
- TS: https://github.com/testing-library/jest-dom/issues/546
- None of the solutions in the issue work with Next.js v14.0.4 and TS v5
## Vitest
- [x] Unit Testing
- [x] Client Components
- [x] Server Components
- [ ] `async` components
- [x] 'server-only'
- [x] Update vitest example
- [x] Handles CSS, and CSS modules imports
- [x] Handles next/image
## Other
- https://github.com/vercel/next.js/issues/47448
- https://github.com/vercel/next.js/issues/47299
This ensures that `export const dynamic = 'force-static'` is properly
honored when a page contains fetches with `cache: 'no-store'`, `cache:
'no-cache'` or `next: { revalidate: 0 }`.
Closes NEXT-1858
Previously when running deployment tests, the testing infrastructure
used the Vercel REST API to manage and work with deployments to perform
the actual testing. This now utilizes the Vercel CLI instead (while
maintaining the same beheviour as before) to simplifiy the
implementation.
In cases where testing is performed against a locally configured Vercel
CLI that's already authenticated it will now use those pre-configured
credentials.
Closes NEXT-1841
Implementation of feature request opened here -
https://github.com/vercel/next.js/discussions/59427
Approach:
~~We are using micromatch in the csrf protection step of actionHandler
to allow for wildcard domains passed in allowedDomains. This is the same
library used for matching domains for remote images.~~
If any of the allowed domains match the origin of the request, we skip
the downstream error thrown for csrf protection.
Edit:
Micromatch is not available in this context as it is only compatible
with Node. This codepath can be run from the edge, so we need to rely on
vanilla js compatible code only.
Instead of falling back to allowing the user to pass in a regex, which
can be somewhat insecure, we opt into continuing to use a wildcard
pattern from a configuration standpoint and instead use a simple
function that matches on wildcards using string comparison and
iteration.
Ideally, Micromatch can be retrofitted to work in non-Node settings and
this piece of code can be replaced in the future, without deprecating or
changing the next.config interface.
---------
Co-authored-by: Josh Story <story@hey.com>
Adds a new field `prefetchRsc` to CacheNode that will be used by the PPR
implementation. It represents a static version of the segment that can
be showed immediately, and may or may not contain dynamic holes. It's
prefetched before a navigation occurs. During rendering, we will choose
whether to render `rsc` or `prefetchRsc` with `useDeferredValue`.
As with the `rsc` field, a value of `null` means no value was provided.
In this case, the LayoutRouter will go straight to rendering the `rsc`
value; if that one is also missing, it will suspend and trigger a lazy
fetch.
The non-PPR implementation will never set this value.
This PR adds the field to the CacheNode type but doesn't implement any
of the behavior yet. Mostly this involves updating the router reducer
unit tests.
Closes NEXT-1855
Passing `NODE_OPTIONS='--inspect'` was failing because a sub-process was
getting created (`getRegistry()`) which would trigger a "address already
in use" error when the process inherited the same debugger port from the
parent process.
I had to disable this test in
https://github.com/vercel/next.js/pull/59508 because it wasn't passing,
CI was just skipping it. This PR fixes the behavior and re-enables the
test.
Fixes#55862
Closes NEXT-1854
I want to give this field a name that's bit less generic and
distinguishes it from `lazyData` (because that one has a different type
and is a special case we want to eventually remove).
I'm also about to add an optional `prefetchRsc` field that represents a
prefetched version of the same value. The common suffix is meant to
communicate how they are related.
Doing this rename in its own PR because it's a pure find-and-replace,
whereas the later steps are not.
Closes NEXT-1846
This was incorrectly setting the upper bound on the `--group` argument
to our test runners (ie, `11/122`), which was causing a lot of tests to
be missed.
Closes NEXT-1851
This updates the `collectGenerateParams` method to use a loop rather
than being recursive as well as updating some of the Typescript types.
This is a follow up of #59420.
Closes NEXT-1839
`CacheNode.data` is used to lazily kick off a request during render, and
represents the result of the entire Flight response. It doesn't
correspond directly to the RSC data of the cache node itself — that's
`subTreeData`. To complicate things further, I'm about to add another
field to CacheNode that represents prefetched RSC data.
To make it a little less confusing, I've renamed the `data` field to
`lazyData`. Still not perfectly clear on first glance, but it's at least
more specific. With PPR, the goal is to remove the lazy data fetching
mechanism in favor of initiating the request immediately upon
navigation. So this field will eventually go away.
In the next PR, I will rename `subTreeData`, too. Perhaps something with
"rsc" in the name so it's less generic than "data".
Closes NEXT-1843
I'm about to make some changes to the CacheNode data structure, and
before I add more complexity, I noticed an opportunity to remove some —
the `status` field isn't logically necessary:
- The `DATA_FETCH` and `LAZY_INITIALIZED` states are already treated as
equivalent; in either case, they will cause the render to suspend during
render, trigger a lazy data fetch (if one hasn't been triggered
already), and then update the router with the result of the response.
- `subTreeData` is null if and only if the node is in the `DATA_FETCH`
or `LAZY_INITIALIZED` states, and it always causes the render to
suspend. So rather than check if the status is one of those, we can
check if `subTreeData` is null.
The most important changes are to CacheNode type in
app-router-context.shared-runtime and the lazy fetching logic in
LayoutRouter. Everything else in the diff is related to deleting the
`status` field wherever a CacheNode is referenced, like in the reducer
unit tests.
Closes NEXT-1842
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](a3616d33ed/test/e2e/app-dir/app-fetch-deduping/app-fetch-deduping.test.ts (L8-L29)).)
- Each time a request is received, write to an event log. Then assert on
the result of the log at different points throughout the test. This
helps catch subtle mistakes where the order of events is not expected,
or the same event happens more than it should.
(I wrote some test helpers, but to avoid early abstraction, I've
intentionally not moved them into a separate module.)
Closes NEXT-1779
We don't want to perform this check for stable releases since those are
never initiated by the cron task, as otherwise it would fail when going
from canary -> stable as no commits would land in-between.
Closes NEXT-1836
