Intercepting routes not work depending on the first page displayed #52748
Comments
AkifumiSato
changed the title
AkifumiSato
changed the title
|
I think this is due to the unintended use of the prefetch cache. |
|
I have bumped into a similar situation here: #53170. My reproduction example also uses parallel routes (for a modal) and route groups (to pick pages that should intercept the route). |
|
@ztanner @feedthejim |
ztanner
added a commit
that referenced
this issue
Dec 22, 2023
### What?
When handling route interception in two different segments but handled
by the same interception route, the first interception will show the
correct component but attempting the same interception on another
segment will return elements from the first request, not the second.
### Why?
Prefetch cache entries are created from the browser URL. However, route
interception makes use of `nextUrl` to mask the underlying components
that are being fetched from the server to handle the request
Consider the following scenario:
```
app
foo
@modal
(...)post
[id]
bar
@modal
(...post)
[id]
post
[id]
```
If you trigger an interception on `/foo`, your URL is going to be masked
to `/post/1` and keyed as such in the prefetch cache. However, the cache
entry is actually associated with `app/foo/@modal/(...post)/[id]`. That
means when you trigger the same interception on `/bar`, it will return
the tree from `/foo`.
### How?
This PR will prefix the prefetch cache key with `state.nextUrl` when
necessary.
Fixes #49878
Fixes #52748
Closes NEXT-1818
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
agustints
pushed a commit
to agustints/next.js
that referenced
this issue
Jan 6, 2024
…#59861) ### What? When handling route interception in two different segments but handled by the same interception route, the first interception will show the correct component but attempting the same interception on another segment will return elements from the first request, not the second. ### Why? Prefetch cache entries are created from the browser URL. However, route interception makes use of `nextUrl` to mask the underlying components that are being fetched from the server to handle the request Consider the following scenario: ``` app foo @modal (...)post [id] bar @modal (...post) [id] post [id] ``` If you trigger an interception on `/foo`, your URL is going to be masked to `/post/1` and keyed as such in the prefetch cache. However, the cache entry is actually associated with `app/foo/@modal/(...post)/[id]`. That means when you trigger the same interception on `/bar`, it will return the tree from `/foo`. ### How? This PR will prefix the prefetch cache key with `state.nextUrl` when necessary. Fixes vercel#49878 Fixes vercel#52748 Closes NEXT-1818
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Verify canary release
Provide environment information
$ next info Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 21.3.0: Wed Jan 5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000 Binaries: Node: 18.13.0 npm: 8.19.3 Yarn: 1.22.19 pnpm: 8.3.1 Relevant Packages: next: 13.4.10-canary.8 eslint-config-next: N/A react: 18.2.0 react-dom: 18.2.0 typescript: 4.9.5 Next.js Config: output: N/AWhich area(s) of Next.js are affected? (leave empty if unsure)
App Router
Link to the code that reproduces this issue or a replay of the bug
https://github.com/AkifumiSato/http-vary-has-not-next-url
I discovered this while investigating another bug.
To Reproduce
Operate normally
http://localhost:3000/feed(full load)http://localhost:3000/photoNot operate normally
http://localhost:3000/(full load)http://localhost:3000/feedhttp://localhost:3000/photoDescribe the Bug
Depending on the first page displayed, the intercepting routes not work properly, and the transition will be as if the intercept directory did not exist.
Expected Behavior
Wherever the first page is, intercepting routes should work.
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
The text was updated successfully, but these errors were encountered: