The example from the documentation doesn't work. Link + [...catchAll] does not close modal window

[MrOxMasTer]

Link to the code that reproduces this issue

https://github.com/hqw567/nextgram

To Reproduce

1. Set up an Intercepting Route in a Next.js application.
2. Navigate to the page that triggers the Intercepting Route.
3. From the Intercepting Route, use router.push('/') or a <Link href={'/'}> element to navigate back to the home page.
4. Notice that the Intercepting Route does not close or unmount as expected.

Current vs. Expected behavior

Current Behavior:
When navigating away from an Intercepting Route using router.push('/') or <Link href={'/'}>, the Intercepting Route's component does not unmount or close, leaving the Intercepting Route's state or UI still active or visible in the background.

Expected Behavior:
Upon navigating away from an Intercepting Route using either router.push('/') or a <Link href={'/'}>, the Intercepting Route's component should unmount and close properly, similar to how it behaves when using router.back(). This ensures a consistent and predictable navigation experience within Next.js applications.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 16320
  Available CPU cores: 6
Binaries:
  Node: 20.12.2
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.1.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.5
Next.js Config:
  output: standalone

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

Parallel & Intercepting Routes

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

next dev (local)

Additional context

#62430

https://nextjs.org/docs/app/building-your-application/routing/parallel-routes#closing-the-modal

It's exactly the same situation. The modal window does not close.

[ztanner]

Hi @MrOxMasTer -- does the modal close for you if you add a @navigation/page.tsx component that returns null? If you're navigating to the index route, it's going to try and match @navigation/page.tsx rather than @navigation/[...catchAll] ([...catchAll] would apply to /foo, /foo/bar, but not /).

I can see how the docs are a bit unclear here, so I'll get those updated.

[MrOxMasTer]

Hi @MrOxMasTer -- does the modal close for you if you add a @navigation/page.tsx component that returns null? If you're navigating to the index route, it's going to try and match @navigation/page.tsx rather than @navigation/[...catchAll] ([...catchAll] would apply to /foo, /foo/bar, but not /).

I can see how the docs are a bit unclear here, so I'll get those updated.

I deleted page.tsx to check, but it was there before and also didn't work on 14.2.3.

[MrOxMasTer]

Hi @MrOxMasTer -- does the modal close for you if you add a @navigation/page.tsx component that returns null? If you're navigating to the index route, it's going to try and match @navigation/page.tsx rather than @navigation/[...catchAll] ([...catchAll] would apply to /foo, /foo/bar, but not /).

I can see how the docs are a bit unclear here, so I'll get those updated.

I read your comment about this and about the suggestion to support [[...catchAll]] in special routes and so also tried your way but it doesn't work still

[MrOxMasTer]

[ztanner]

Hi @MrOxMasTer -- does the modal close for you if you add a @navigation/page.tsx component that returns null? If you're navigating to the index route, it's going to try and match @navigation/page.tsx rather than @navigation/[...catchAll] ([...catchAll] would apply to /foo, /foo/bar, but not /).
I can see how the docs are a bit unclear here, so I'll get those updated.

I deleted page.tsx to check, but it was there before and also didn't work on 14.2.3.

I tried your provided reproduction and it works fine if I add a app/@modal/page.tsx component that returns null.

CleanShot.2024-04-26.at.14.05.12.mp4

Please provide an updated reproduction for us to look into this for you. Thanks!

[MrOxMasTer]

Please provide an updated reproduction for us to look into this for you. Thanks!

So, I deleted the .next folder and ran it again and it worked!

Then let me ask you another question. Do I understand correctly that in this situation it can only lead to the home page? It seems logical, because the link is to the main page, but maybe somehow it can be realised by intercepts?

Because when testing on other pages, it doesn't return to the main page all the time.

[MrOxMasTer]

Do I understand correctly that whenever the window is closed, it will always lead to '/' and not to the pages the user was on before when approaching Link + [...catchAll] + page.tsx?

[ztanner]

It will go wherever you specify in your router.push call (to dismiss the modal).

If you don’t want the user to leave the page they were on when they triggered the modal, I imagine you could use router.back() instead? (To bring them back to the page before the interception was triggered)

[MrOxMasTer]

Yes, I was just using router.back() before. I was thinking that it might be possible to use links to implement modal window closing, so that in any case the user could close the window even with js disabled.

I realise that it would be rare to have disabled js, but still. I thought that this 2 way will help to make less client code and secure the user to at least go to the main page when js is disabled.

But with this method, we take away the user's ability to return to the page they were on before, and that doesn't look good from a user experience perspective

[ztanner]

If JavaScript was disabled, how would they trigger the route interception?

[MrOxMasTer]

No way. There would be a regular modal component (for on/off js). The close button would be Link + href='/'. With js enabled, it would take the user to the page he was on before opening the modal window, and with it disabled, it would always take him to the main page.

But good idea by the way. If js is present, it opens the intercepting route and there router.back(), and if js is disabled, it includes the usual page '/menu' and so Link + href=‘/’

Honestly, that's roughly how I imagined this method would work. That thanks to [...catchAll] it would somehow return to the page the user was on before the modal window was opened. (Thought it would catch all links sent from @modal and that would somehow work)

[MrOxMasTer]

Hmm, I’m not sure I understand the question, could you clarify?

Because, for example, I was on the auth page:

I go to the modal window

and when closing I get to the main page and it's like it's not really convenient with this approach or I don't understand something

[MrOxMasTer]

Hmm, I’m not sure I understand the question, could you clarify?

Maybe it's not supposed to happen that way? There are just very few scenarios using this approach, when every time the modal window closed it took me to the main page (‘/’) and it's not a good user experience