Next.js gives 404 on Intercepting Routes with nested route groups #59279
Labels
bug
Issue was opened via the bug report template.
linear: next
Confirmed issue that is tracked by the Next.js team.
locked
Comments
balazsorban44
added
the
linear: next
|
It looks like it's related to #58296 |
ztanner
added a commit
that referenced
this issue
Dec 20, 2023
### What? Navigating to a layout that is part of a route group that uses route interception currently will trigger a 404 error if the route group doesn't define a `default` segment. ### Why? When `next-app-loader` injects fallback defaults into the loader tree, it does so by first seeing if a default already exists. However it does this without ignoring route groups, meaning if you have a `/app/default.tsx` and your interception route is at `/app/(level1)/(level2)`, it will look for the default at `/app/(level1)/(level2)/default.tsx`. When a `default` isn't found, the fallback behavior is to trigger a `notFound()` error. This means navigating to the intercepting route that has no `default` for the `children` segment will 404. ### How? This adjusts the fallback behavior by attempting to find the `default` by normalizing the segment path, which will ignore route groups. That way `/app/(level1)/(level2)/default` will first check `/app/default.tsx` before falling back to `notFound` behavior. Fixes #59279 Closes NEXT-1813
|
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
…el#59752) ### What? Navigating to a layout that is part of a route group that uses route interception currently will trigger a 404 error if the route group doesn't define a `default` segment. ### Why? When `next-app-loader` injects fallback defaults into the loader tree, it does so by first seeing if a default already exists. However it does this without ignoring route groups, meaning if you have a `/app/default.tsx` and your interception route is at `/app/(level1)/(level2)`, it will look for the default at `/app/(level1)/(level2)/default.tsx`. When a `default` isn't found, the fallback behavior is to trigger a `notFound()` error. This means navigating to the intercepting route that has no `default` for the `children` segment will 404. ### How? This adjusts the fallback behavior by attempting to find the `default` by normalizing the segment path, which will ignore route groups. That way `/app/(level1)/(level2)/default` will first check `/app/default.tsx` before falling back to `notFound` behavior. Fixes vercel#59279 Closes NEXT-1813
|
This is actually expected behavior as you're switching layouts (in the repro even the root layout) |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Link to the code that reproduces this issue
https://github.com/fedetorre/nextgram
To Reproduce
I have a complex nextjs project with the same problem, I tried to reproduce my project structure with the nextgram demo for debugging purpuse.
Steps to reproduce:
Current vs. Expected behavior
I'm expecting that the modal opens with the image and the 404 page will not be rendered.
Verify canary release
Provide environment information
Operating System: Platform: linux Arch: x64 Version: #38~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 2 18:01:13 UTC 2 Binaries: Node: 18.19.0 npm: 10.2.3 Yarn: 1.22.21 pnpm: N/A Relevant Packages: next: 14.0.4-canary.40 eslint-config-next: N/A react: 18.2.0 react-dom: 18.2.0 typescript: 5.1.3 Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
Not sure, App Router
Additional context
This is the current behaviour
Screencast from 05-12-2023 10:19:44.webm.
My production application is deployed on vercel but the problem also exists on local development environment.
NEXT-1813
The text was updated successfully, but these errors were encountered: