Why do slots fall back to the previously active state and not the default?

[amir-s]

I'm using the app router for a dashboard i'm creating. The Layout has the {props.children}, and also a {props.subMenu} for a parallel route, so the sub pages can have customized sub menus on the header which is on the main layout.

I thought I can just setup a default.tsx with () => null component so not all the sub pages need to define a sub menu, and if they don't, it'll be empty. But that's not how it works. The sub menu is persisted between client side navigations if I go from a page that has sub menu to a page that doesn't. Only if I do a hard reload the sub menu disappears. I thought this might be a bug but in the docs about parallel routes it says:

Navigation
On navigation, Next.js will render the slot's previously active state, even if it doesn't match the current URL.

Reload
On reload, Next.js will first try to render the unmatched slot's default.js file. If that's not available, a 404 gets rendered.

so this is by design, but I don't understand what's the use-case for that and why it has been designed that way.

[finnmerlett]

+1000 this seems like really unintuitive behaviour. I just do not get why you should ever get different results when navigating vs visiting by url / hard reloading. Even the url interception feature seems difficult to grasp and unclear what the outcome of using it will be, but at least you have to active decide to enable that. The fact that for the inconsistent slot fallback behaviour, the docs just say it is thusly, and give no explanation for why or any way to turn it off infuriates me.

[doomietrue]

I'm puzzled by a particular challenge: I aim to implement a Layout with slots for Header and Sidebar. The complication arises on one unique page where the Header and Sidebar have a slightly altered appearance. I wish to maintain some client-side state for the Sidebar, like the state of a collapsed accordion which in this case works. However, the issue I'm encountering is when the Sidebar is rendered with the accordion and the user moves to a different page, the transition doesn't seem to recognize the change in the route.

The documentation is saying that "On navigation, Next.js will render the slot's previously active state, even if it doesn't match the current URL." but it doesn't explain why. Would be nice to have a possibility to somehow opt out of this behavior for individual slots.

[nphmuller]

I also am a bit stumped by this behavior. As a workaround I removed the default.ts fallback and implemented the slot for every route. The routes that don’t need to slot simply render a component that returns null. A bit more work, but it’s doable I guess.

[vmukhteev]

As a workaround I use [...]/page.tsx instead of default.tsx.

[stnmonroe]

I tried this one, and after an intercepted route it works going backward, but broke the appropriate slot updates moving forward. Also, was using (...) not [...]. I assume you were as well, or maybe this is why it wasn't working. I did not get any response using square brackets.

[artem-prudnikov]

@stnmonroe
I used [...] and it now works back and forth. Had to restart NextJS app for the changes to apply.

[icopp]

I agree 100%. This is intensely unintuitive behavior and is hard to design around. I feel like everyone can, or should, agree that the page rendering behavior on navigation, and on a new refresh, should always be exactly the same except for the very specific case of a feature like intercepting routes that exists entirely to preclude normal navigation.