-
Notifications
You must be signed in to change notification settings - Fork 27.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parallel / Intercepting Routes rendering 404 on page load #48289
Comments
the link to the reproduction code is broken. can you update it ? |
@Fredkiss3 I am having similar issues so I tried to build a reproduction codebase here: https://codesandbox.io/p/sandbox/nextjs-intercepting-routes-s9j6mo If you click Not sure if this is the exact problem he is describing, because I also have an issue with a 404 locally, but cannot reproduce right now in a codesandbox. |
@feedthejim I think there is still something wrong with the
I modified this repo to use the old (..) syntax here: https://codesandbox.io/p/sandbox/nextjs-intercepting-routes-forked-bfuitc |
Maybe related to #48090 ? |
I have some similar issue… When I have:
Everything is working, except If I will change More details, using the example by given link in Vercel NextJS documentation: /~https://github.com/vercel-labs/nextgram/tree/main/app for interceptor Modal example, and I see that
My setup package.json has |
Shortly, If I will clone /~https://github.com/vercel-labs/nextgram/tree/main and update
the update from |
After some time, I did file move from /~https://github.com/conmute/fireship-nextjs/tree/main/app/src/app/%40modal |
OMG — I think I've figured this out! I was running into the same problem: the intercepted route would load fine when clicking a Here's the problem: if the layout slot isn't filled based on the current path, it will 404. You can test this by removing the slot from the layout file, and then doing a full-page load on the intercepted route path. The full-page load should work just fine now. Then, when you add the slot back to the layout file, it'll 404 again. To fix this, you need to use a route group. Remove the slot from your root layout, and create a new layout inside your route group that just renders // src/app/(home)/layout.tsx
import { ReactNode } from 'react'
export default function Layout({
children,
slotNameHere,
}: {
children: ReactNode
slotNameHere: ReactNode
}) {
return (
<>
{children}
{slotNameHere}
</>
)
} Move your homepage and your intercepted routes underneath your route group:
Note that, if your intercepted route is a few levels down (e.g., |
I am facing a similar bug, the details are here: #53170 @jessepinho, I am unable to fix 404s with the group. Since you are saying that you have figured it out, can it be that my reproduction example is just misconfigured? If you can spot a missing bit that is causing 404s, that’ll be awesome! |
@kachkaev I don't have more time to look into it, but it looks like you're using three dots in the name of your |
@jessepinho three dots refer to root app directory so they are fine I guess. My reproduction in #53170 works the same way for |
Intercepting and parallel routes seem completely broken to me... or the docs are completely wrong. Either way, this is a very frustrating issue. The group solution did not work for me. |
The "trick" to this is to use default.tsx to cover non-matching slots. Adapting the example app worked for my use case |
This comment was marked as off-topic.
This comment was marked as off-topic.
I agree with @jscul on this one, so much of this seems completely broken and half baked. The docs are not correct. |
has any fix been applied for this? |
I'm using js rather than tsx, and I have a
My hierarchy (borrowed from the "nextgram" example) is:
I develop in vscode on a remote (linux) system. Here is the complaint I get in the embedded terminal of vscode
So far as I can tell, this is an issue from According to I run the most recent Javascript version of It looks to me as though v13.5.4 does not align with the documentation or the |
@SomervilleTom take a look here /~https://github.com/vercel-labs/nextgram/tree/main/src/app/%40modal. They use
Also seems like nextgram uses v13.4.7. I just had to downgrade because I kept getting |
@kshyr: Interesting. Please note that I wrote my version based on the most recent JAVASCRIPT (as opposed to tsx) version of the example. I note that in this earlier version, the
I changed my code to use the single-level intercepting route (
My read of this stack trace is that the I need modal dialogs. I guess it's time to start seeking some sort of work-around. Since the "AppRouter" functionality seems to be broken, perhaps I need either somehow code modal behavior myself, revert to the "pages" paradigm, or find a way to patch this bug. |
I spent the last several hours refactoring my version of I added 'console.log' statements to each The result is that, as far as I can tell, the intercepting route is simply ignored. Here is my new structure:
The top-level 'page.js' ( In this version, when one of those is clicked, the plain (non-modal) At no time is there any evidence that any It appears to me that in the v13.5.4 release, parallel/intercepting routes are either broken or do nothing. |
I spent the rest of the afternoon trying to patch v13.4.7 (the version used in the most recent My next step is to punt the "AppRoute" approach altogether, at least for now, and revert to the less-favored "Pages" approach. I don't need to do any streaming, so perhaps this will be more fruitful. At least for now, the APIRoute approach is a dead-end for me. |
I was finally able to get a copy of the
Please note that I am using Javascript ('.js') rather than Typescript ('.ts'). Now that I have the If that succeeds, then I'll try adding back the MaterialUI code (MaterialUI is the point of the exercise for me). I note the dependency on |
I updated to v13.5.4 and all is still well (running the 'nextgram' example). I removed the "experimental" section from Now I'll try adding back in the MUI behavior (piece by piece). |
Hey, pretty sure this bug has been fixed but not included in a major release yet. I updated to 13.5.4-canary.6 which fixed the MUI issues |
I was finally able to apply a patch to "start-server.js" for v13.5.4 so that 'yarn dev' starts a dev server listening on https instead of http, using the No console complaints, and the MUI version of 'nextgram' behaves as expected. I'm finally able to resume development on my own MUI modal behavior. NOTE: I'm pretty sure that adding |
I'm gonna close this issue because it seems while it's clear people are having various issues with parallel routes, it's unclear to me if they are not related to the original issue in particular. Please open new issues with repros and a description of what doesn't work, and feel free to ping me directly there, I promise to take a look. |
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. |
Verify canary release
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 22.4.0: Mon Mar 6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 Binaries: Node: 18.13.0 npm: 9.4.0 Yarn: 1.22.19 pnpm: N/A Relevant packages: next: 13.3.1-canary.4 eslint-config-next: 13.3.0 react: 18.2.0 react-dom: 18.2.0
Which area(s) of Next.js are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue
https://vercelnextjsnzcvbl-dh2v--3000--b5037fed.local-credentialless.webcontainer.io/1
To Reproduce
Describe the Bug
Upon initial client-side navigation to an intercepted route, the page is properly navigated and modal is shown. Upon reloading the page the content is not rendered, get a 404 page but params are still passed.
Expected Behavior
Navigation should first show modal on initial load from top level page. After reloading the parent page should be loaded, not have 404 but still receive props
The intention is to have a blog page with a list of articles with a set of ids (a,b,c..) which are conditionally rendered in a modal while on the blog page itself, are rendered standalone when visiting from a link / page is reloaded.
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: