Parallel routes do not clear slot with [...catchAll]

[Yukioru]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
Binaries:
  Node: 19.7.0
  npm: 9.5.0
  Yarn: N/A
  pnpm: 8.8.0
Relevant Packages:
  next: 13.5.4-canary.1
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue

/~https://github.com/Yukioru/next-parallel-routes-bug
https://codesandbox.io/p/github/Yukioru/next-parallel-routes-bug/main
https://next-parallel-routes-bug.vercel.app

To Reproduce

You have to use soft navigation

1. Click "To /overview" page
2. Slot displays correctly with contents of the "Overview Extension"
3. Click "To /demo" page
4. The slot has not cleared

Describe the Bug

Once the slot is shown, it is not cleared if the URL does not match.
A similar bug has already been described in Issue: #48124, but the solution with [...catchAll] route did not help. The route is not called.

If you do a hard navigation, you will see that the /demo slot segment corresponds to the default.js route, but it does not show up.

Expected Behavior

Using soft navigation (next/link) the slot should be cleared by the [...catchAll] route (or the default.js route if possible).

Which browser are you using? (if relevant)

Chrome 112.0.5615.138

How are you deploying your application? (if relevant)

Vercel, CodeSandbox

_NEXT-1394

[y0zong]

like I mentioned here#48090, it seems dynamic route or catch-all route still not compatible with parallel route, I think it may have some work to do.

[Yukioru]

Did a little research on the code - the essence of the problem is that all /[...catchAll] match only with [...catchAll] pages. When the situation arises that [...catchAll] the route is only in the parallel segment, but not on the page - the router will wait for the transition to the [...catchAll] page (if in my Issue go to a non-existent page, the segment will be called).

It seems that appPaths should contain any of the [...catchAll] being in a segment (but not necessarily having a page) considering nesting.

next.js/packages/next/src/server/dev/next-dev-server.ts

Lines 568 to 573 in cad6d3a

	const originalPageName = pageName
	pageName = normalizeAppPath(pageName).replace(/%5F/g, '_')
	if (!appPaths[pageName]) {
	appPaths[pageName] = []
	}
	appPaths[pageName].push(originalPageName)

Perhaps there is a similar code in other packages for generating pages (I could not find it correctly)..

---

For example
Now page matchers look like this:

{
  "/": ["/page", "/@extension/page"],
  "/[...catchAll]": ["/@extension/[...catchAll]/page"],
  "/overview": ["/overview/page", "/@extension/overview/page"],
  "/demo": ["/demo/page"]
}

But they should look like this:

{
  "/": ["/page", "/@extension/page"],
  "/[...catchAll]": ["/@extension/[...catchAll]/page"],
  "/overview": ["/overview/page", "/@extension/overview/page"],
  "/demo": ["/demo/page", "/@extension/[...catchAll]/page"]
}

[adidoes]

I just ran into this issue on 13.4.7. Has anyone found a workaround?

[oswaldoacauan]

Any updates on this? Right now feels impossible to use Parallel routes with Dynamic routes.

[tangye1234]

Any progress?

[miro-zone]

tired many things nothing work just route.back() ... and yeah still we need fix.

[Yukioru]

Updated the issue to the latest canary version 13.5.4-canary.1
🗿waiting..

[tangye1234]

Updated the issue to the latest canary version 13.5.4-canary.1
🗿waiting..

Could you see this issue? The whole app is unmounted in the case described there without any error.

[gragland]

Here's a workaround:

app
├─ @photoModal
│  ├─ (.)photo
|  |  └─ [id]
│  │  |  └─ page.tsx <----- a modal with links to home, /profile, and /login
│  └─ [...catchAll]
│  │  └─ page.tsx <----- returning null here is supposed to cause modal to hide when
│  │  │                  navigating away, as this should match all other routes, doesn't work though.
│  │  │                  So we create dummy pages to match the specific routes below.
│  └─ profile             
│  │  └─ page.tsx <----- page that returns null, causing modal to hide when navigating to /profile
│  └─ login
│  │  └─ page.tsx <----- page that returns null, causing modal to hide when navigating to /login
|  └─ page.tsx <----- page that returns null, causing modal to hide when navigating to /
|  └─ default.tsx
├─ photo
|  └─ [id] 
|  |  └─ page.tsx 
├─ profile
│  └─ page.tsx
|  login
|  └─ page.tsx
└─ page.tsx

Dummy page looks like this:

export default function Page() {
  return null
}

[stefanofa]

Since I ran into the same problem, I also created a simple codesandbox.

The desired result is that the subheader that is displayed following a soft navigation to /c is "I'm the catchall subheader!"

[stefanofa]

I have created a draft PR with failed tests and further context, if anyone would like to add feedback please feel free to do so.

[feedthejim]

thanks @stefanofa for adding a repro. I was looking into this and you're right that it should work. I'll try to fix this in the next one-two weeks. It's not super straightforward to fix unfortunately.

[stefanofa]

Thanks @feedthejim for taking care of it. Since this is part of the topic, I have a question to ask, namely why do the slots during soft navigation behave as described in the docs?

Thinking about it I can't think of any concrete use cases, although I'm most likely missing something.

[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.