Dynamic segment parallel route does not match static normal route

[michaelschufi]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/parallel-routes-params-forked-jtjfkr

To Reproduce

1. Open the sandbox
2. Click on the second link
3. Observe the parallel route slot not matching.

Current vs. Expected behavior

I expected the dynamic route folder structure inside the @parallel slot @parallel/test/[testParam] of the slot to match the /test/static route, like a "normal" implicit children-slot folder structure would.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 14.1.1-canary.78 // Latest available version is detected (14.1.1-canary.78).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router, Routing (next/router, next/navigation, next/link)

Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local)

Additional context

I found this, while looking for a workaround for #62539. Since it would've made that bug a bit easier to work around.

I've tried it on the current stable version of next@14.1.0 as well, where it also doesn't work.

Note: I haven't tested it in deployed environments, because that seems out of scope.

[coffeecupjapan]

@michaelschufi
Hi. I think it is hard to implement the function that /test/static is matched with parallel route /test/[testParams] since below code only check /test/[testParams] is included in /test/static.

next.js/packages/next/src/server/future/route-matcher-providers/dev/dev-app-page-route-matcher-provider.ts

Line 58 in d01d6d9

if (pathname in appPaths) appPaths[pathname].push(page)

Maybe you should try making /test/static under @parallel path or ask maintainer to implement it (however it is not a few lines change fix I guess).

[michaelschufi]

Thanks for your response @coffeecupjapan

My point is, together with the catch-all route not working, you have to mirror the whole routing structure just to display a slot properly. Which feels wrong and bug-like.

Also, I think it's currently counter-intuitive, because I expect the params definitions are not shared with all other slots. Because if they are, the whole "filesystem routing" makes less sense. With the current behaviour, whenever you add a route, you need to add the same route for all the slots.
If the routes of different slots have to match up together, it would make way more sense to just have alternate page files in the structure.

Why do we have to do this:

app-with-slots
├── @mySlot
│   ├── [slug]
│   │   ├── page.tsx
│   │   └── something
│   │       ├── [...segments]
│   │       │   └── page.tsx
│   │       └── page.tsx
│   ├── other
│   │   ├── [id]
│   │   │   └── page.tsx
│   │   ├── more-nesting
│   │   │   └── page.tsx
│   │   └── page.tsx
│   └── page.tsx
├── [slug]
│   ├── page.tsx
│   └── something
│       ├── [...segments]
│       │   └── page.tsx
│       └── page.tsx
├── other
│   ├── [id]
│   │   └── page.tsx
│   ├── more-nesting
│   │   └── page.tsx
│   └── page.tsx
└── page.tsx

If we could just do this (since the folders have to match anyways...)

app-with-slots-2
├── @mySlot-page.tsx
├── [slug]
│   ├── @mySlot-page.tsx
│   ├── page.tsx
│   └── something
│       ├── @mySlot-page.tsx
│       ├── [...segments]
│       │   ├── @mySlot-page.tsx
│       │   └── page.tsx
│       └── page.tsx
├── other
│   ├── @mySlot-page.tsx
│   ├── [id]
│   │   ├── @mySlot-page.tsx
│   │   └── page.tsx
│   ├── more-nesting
│   │   ├── @mySlot-page.tsx
│   │   └── page.tsx
│   └── page.tsx
└── page.tsx

For me, the first approach only really makes sense, if I can independently define params in each slot.

[coffeecupjapan]

@michaelschufi
OK. I see.
It is exactly troublesome to mirror the whole routing structure as you said.

        const ParallelContainedPath = Object.values(appPaths).filter((paths) => {
            return paths.some((path) => path.startsWith("/@")) && paths.length > 1
        })
        .map((paths) => paths.filter((path) => path.startsWith("/@")))
        .flat();
        let fixedAppPaths = appPaths;
        ParallelContainedPath.forEach((parallelPath) => {
            const mainPath = parallelPath.replace("/@", "").split("/").slice(1).join("/");
            const mainPathRegexp = new RegExp(mainPath.replace(/\[\w+\]/g, "\\w+"))
            Object.entries(fixedAppPaths).forEach(([key, value]) => {
                if (value.includes(parallelPath) || !value.some((path) => path.match(mainPathRegexp))){
                    fixedAppPaths[key] = value;
                    return;
                }
                fixedAppPaths[key] = [...value, parallelPath];
            });
        });
        appPaths = fixedAppPaths

So, I try to make a patch for it and it works fine for your case ( I am not testing whole cases though, like case that has more than two parallel paths or so on ) for above codes added under the blank line here.

next.js/packages/next/src/server/future/route-matcher-providers/dev/dev-app-page-route-matcher-provider.ts

Line 61 in d01d6d9

I don't think my codes are good, so you can ask any maintainer to hackle this issue. I think it is doable ( Because although I am not super expert on Next.js, I can write a super easy patch ).

[michaelschufi]

Hi @coffeecupjapan

Thanks for the message! This looks promising :D

I think we could first validate that the current behavior is unintended, or at least can be improved upon. It's important, that we get the correct params as well, depending on what page-file we are in, that it doesn't conflict with e.g. intercepting routes, etc.

[coffeecupjapan]

@michaelschufi
I think Next.js is not considering partial slot of static route to be rendered as that of dynamic route, and it is intended not bug. But I'll ask maintainer about this issue.

@wyattjoh
There is a request for the function that can omit effort to write partial slot of static route when partial slot of dynamic route is defined.
For example, if you define /[dynamic] and /static and /@partial/[dynamic] and /@partial/default 4 routes, using this function, /static renders partial route as @partial/[dynamic] instead of default and you don't have to add /@partial/static. Currently, displays @partial/default or if you add @partial/static this @partial/static is displayed.

And I investigate for dev env and find that if dynamic partial path can be include for /static route matcher in transform function of dev-app-page-route-matcher-provider.ts, it works fine just for a single simple case above.

So I want to ask you that whether this function is doable or not, since you contribute most for dev-app-page-route-matcher-provider.ts.
It can reduce user's effort to write absolute same files for static partial paths (but user cannot customize custom partial route for static I guess ).

[ztanner]

Hi @michaelschufi -- now that we landed better catch-all support in #65063, I think you should be able to use a catch-all to achieve what you're looking for! As of my writing, it's available on canary.

I'm going to close this issue, but let us know if you're still unable to get it working and we can investigate further.

[github-actions]

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.