Nested navigation withBackwardNavigation

Support
1

Hello!
I have a nested navigation :
1. A parent detail view, opened from a list
2. From this view, I open a child detail view using list_edit (navigation mode)
3. From the child view, I open another detail view (third level) using viewNavigators.detailView(…).withBackwardNavigation(true).navigate()

When I close the third-level detail view, I correctly return to the child detail view (level 2).
However, when I then close the child detail view, I am redirected to the list view instead of returning to the original parent detail view.
With multiple nested routed views, what is the recommended way to preserve or control navigation history,
Thank you!

3

Hello,

A few months later, we are still looking for an answer.

As a workaround, I implemented my own navigation history by listening to Vaadin’s AfterNavigationEvent, which allows me to navigate back and forth when the navigation depth is greater than 1.

Now I am wondering:

  • Will Jmix provide a more robust implementation of withBackwardNavigation() in a future update for deeply nested routed views?

  • Is relying on Vaadin’s AfterNavigationEvent considered stable enough, or could future Vaadin updates change its behavior and break this approach?

Thank you!

4

Hi,

The main limitation is that a full nested navigation stack can only be maintained reliably when the framework controls every navigation action. For example, when navigation is performed programmatically through ViewNavigators, Jmix can add additional information to the navigation operation and remember where the view is expected to return. This makes simple backward navigation possible.

However, routed views are not opened only through programmatic navigation. A view may also contain ordinary links, router links, menu items, custom buttons, browser Back/Forward navigation, redirects, and so on. Any of these can change the current route.

This makes a reliable arbitrary-depth application-level navigation stack very difficult to implement.

One of the key problems is that not every route change can be safely classified. From the framework point of view, navigation from inside a view and navigation from a side menu may both appear as link navigation events. In practice, Vaadin navigation events do not always provide a sufficiently reliable navigationTrigger value that would allow Jmix to distinguish cases such as:

user clicked a link inside the current detail view

from:

user clicked a menu item and started a new navigation flow

These two cases should affect the stack differently. The first one could be interpreted as “go deeper in the current flow”, while the second one should probably reset the current flow. If the framework cannot distinguish them reliably, maintaining a hidden stack becomes error-prone.

That is why Jmix does not try to guarantee an unlimited stack of nested routed detail views. withBackwardNavigation(true) should be considered a convenience mechanism for simple controlled navigation scenarios, not a full application-owned navigation stack.

For route-based navigation, the recommended approach is usually not to model the UI as a stack of opened views. A better pattern is to make the hierarchy explicit in the URL and navigation structure: for example, use routes that represent the current path in the domain model and build breadcrumbs from that path or from a site-map-like structure. Then the user can move between levels using explicit links/breadcrumbs instead of relying on an implicit browser-like navigation stack.

For now, we have no plans to implement a site-map-like structure like this. Jmix provides the Tabbed Mode add-on that supports opening multiple views within the same main view tab, creating a view stack represented by breadcrumbs.

Regards,
Gleb