Next.js's implementation includes a custom Thenable type based on a
similar one used in React's codebase. It was used to implement a
userspace equivalent of the React.use API before that API became stable,
by throwing a promise-like object and tracking the status on an expando
field. However, it didn't cover all the same cases and behaviors that
React.use does, which led to some subtle bugs like the one fixed by
@ztanner in https://github.com/vercel/next.js/pull/55690.
Now that React.use is stable, and we use that for suspending instead of
throwing a promise, we no longer need our custom Thenable type. I've
removed the type and associated functions, and updated our types to use
Promise instead.
Even in cases where a function does return a thenable-object rather than
a native promise, like React Flight's createFromFetch, we should use
TypeScript's built-in PromiseLike utility. Currently, though, we always
await these objects anyway (in fetch-server-response.ts), which turns
them into promises. So Promise is almost always sufficient.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR fixes a bug where parallel routes would not apply appropriately on navigation when used within slots.
The following scenarios:
```
/foo
/bar
/@slot
/[...catchAll]
```
or
```
/foo
/[...catchAll]
/@slot
/bar
```
will now function correctly when accessing /foo/bar, and Next.js will render both /bar and the catchall slots.
The issue was that the tree constructed by `next-app-loader` for a given path, /foo/bar in the example, would not include the paths for the catch-all files at build time. The routing was done 1-1 when compiling files, where a path would only match one file, with parallel routes, a path could hit a defined path but also a catch all route at the same time in a different slot.
The fix consists of adding another normalisation layer that will look for all catch-all in `appPaths` and iterate over the other paths and add the relevant information when needed.
The tricky part was making sure that we only included the relevant paths to the loader: we don't want to overwrite a slot with a catch all if there's already a more specific subpath in that slot, i.e. if there's /foo/@slot/bar/page.js, no need to inject /foo/@slot/bar/[...catchAll].
One thing that is not supported right now is optional catch all routes, will add later.
fixes#48719fixes#49662
### What
Apply correct url rewrite behavior in the specific context (pages/api).
This won't change anything yet, but it will prevent breaking changes when turbopack makes future changes.
Instead of requiring React in `maybePostpone` (which is susceptible to referencing the wrong version of React during build time, such as in the case where the static worker patches fetch within an app-route, which doesn't have an experimental runtime), this provides the postpone API to the `staticGenerationStore`. That way we know the API is available in render which is when we'd expect to postpone.
The "postpone" terminology is internal to React and can be used for more
things than just this. It's also a mechanism we may or may not rely on.
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Fixes a broken link, shortens the title, and adds another possible way
to resolve the error.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR fixes the bug in which interception routes of the form `(.)[param]` would not intercept navigations.
The bug happened because we would not create a dynamic route matcher for the intercepted route, so we would never match the correct dynamic route when hitting the server, falling back to the base one.
The fix consists of fixing the logic that checks for a dynamic route so that it checks the correct path when handling an interception route.
There's probably a better fix here, advice welcome
fixes#52533
React can emit a `Link:` header for preloads instead of `<link
rel="preload">` in certain scenarios when that can be useful. This works
by listening to the `onHeaders` event.
In particular it's interesting for PPR because if you have something
dynamic outside a Suspense boundary it generates an empty payload
without any preloads in it. That's because when we do render the real
shell we don't know what the document will look like. However, we can
emit the `Link` header for CSS, images and font preloads that we've
already discovered. In effect, even a dynamic page gets PPR benefits by
early fetching resources.
Custom headers is supported for static a ROUTE but not a PAGE. So I had
to add similar wiring to forward headers when it's a page being
rendered.
It's important that this works every where, including dynamic routes,
because otherwise we might miss out on preloads that we previously
would've had.
Fixes two build output logs:
- A page that uses `generateStaticParams` & postpones should be marked as partially prerendered
- Assume pages that contain dynamic segments will postpone when PPR is enabled even though it won't be determined until request time
### What
Corrects how urlassetreference reads its assets path to allow to resolve image assets correctly.
There is a test failure in the integration/url still, that involves probably larger refactoring so making this PR first to enable baseline, ensure further refactoring does not breaks anything.
Reverts vercel/next.js#57154
Brings back the changes but uses the compiled version of async-retry instead. Previously these changes causes an error as async-retry wasn't installed.
