Allow custom back-navigation

[probert94]

Describe the current way to archive your requirement The back-navigation is currently hardcoded and uses a history.back or a ../. If someone opens a "deep" link to my application, a history.back would lead him to the previous page which might be the browsers start page or anything else. In my app I would like to open the logical parent instead.

Describe the solution you'd like A possible solution would be to provide a href-generator, which is a Function which gets the current Route and provides the link. This link could then be used as a href. In this case, the back-button would need to be a a-Tag, containing the Icon. Ideally, it would use the route-link attribute to handle the navigation without page-reload.

[appreciated]

The back-navigation is currently hardcoded and uses a history.back or a ../. If someone opens a "deep" link to my application, a history.back would lead him to the previous page which might be the browsers start page or anything else.

This is pretty much the standard behaviour the users expect from an Android App, I am actually pretty satisfied with the current implementation.

Surly I would accept an alternative solution but not if it breaks the current behaviour.

[probert94]

@appreciated I am currently using the FastHub Github-app for android and navigated to this issue using the link in the notification mail. Now, if I press the back-button on the top left, I mavigate back to the issue-list while when I press the systems back-button, I'll go back to the mail app. This is the behavior I would lime to have for my vaadin-app. The back-button in the app should be used for "up"-navigation (contextual back) while the browsers back button should navigate back through the history.

[appreciated]

I am a little confused. So it's fine? 😅

[probert94]

The current behavior of the AppLayouts back-button executes a history.back if the history contains entries and a ../ otherwise. So in most cases it does the same thing as the browsers back-button. In my opinion, this behavior should be customizable to provide a so called "up"-navigation which is a common behavior in android apps. Basically the "up"-navigation navigates to the logical parent within the app, while the back navigation navigates to the previous visited screen, which might be another application.

Example: I have an app with a list of clients. This list is accessed using the Route "my-app/clients". Clicking on a client opens the detail of it. This detail is accessed using the Route "my-app/clients/1", where "1" is the clients ID. Now If I post a link to the client 1 here on github, clicking on it would directly open this clients detail. Using the browsers back-button would execute a "back"-navigation and you would be here on github again. Using the "up"-navigation instead, I would go to the client list ("my-app/clients").

[appreciated]

So: Back navigation ~= history.back Up navigation ~= ../

[appreciated]

And you prefer Up navigation over Back navigation which makes kind of sense.

[probert94]

In most cases "up"-navigation would probably be a "../" but only if you define your routes this way. You could also have a Route "my-app/dashboard" from where you can navigate to a Route "my-app/documents". In that case a "../" would not be correct, the "up"-navigation.

[appreciated]

Does Vaadin flow share the routes with the client side 🤔? If not so this can be done to provide proper up-navigation.

[probert94]

I am not sure about that, but the HasBackNavigation might provide a link, which is used for up-navigation?

[appreciated]

I think that this specific class is pretty useless 😀. #forremoval

[appreciated]

I just refactored the Back navigation a bit. Maybe you've some different ideas but I think this is the way to got. Only thing that need to be done is to pass the parent url to the client side, to save the server round-trip.

[probert94]

The referenced-commit only includes the logic to check, if a back-navigation is possible or not right?

[appreciated]

The referenced-commit only includes the logic to check, if a back-navigation is possible or not right?

Actually up navigation but yes

[probert94]

@appreciated I was thinking about this issue again and came up with another idea: What if we let the users specify the displayed Component? This would give them a lot more flexibility. At the moment there is a paper-button which changes it's icon and behaviour if back-navigation is possible. But this paper-button might not fit the style of the website or one might preffer different icons. My idea is, that the user can specify a Component for the menu-button and one for the back-button. This way, one could easily use a <a href="up-link" router-link> to implement up-navigation. If no components are specified, I would fallback to the current version. What do you say?

[appreciated]

@appreciated I was thinking about this issue again and came up with another idea: What if we let the users specify the displayed Component? This would give them a lot more flexibility. At the moment there is a paper-button which changes it's icon and behaviour if back-navigation is possible. But this paper-button might not fit the style of the website or one might preffer different icons. My idea is, that the user can specify a Component for the menu-button and one for the back-button. This way, one could easily use a <a href="up-link" router-link> to implement up-navigation. If no components are specified, I would fallback to the current version. What do you say?

This can be done, but has some drawback, I can already see many users doing the up-navigation on the server side. Nethertheless it should be allowed to switch out the navigation component, and I agree that there should always be a ready-to-go implementation to keep things easy.

By the way I just found, that the principle of the Up Navigation has changed. Which makes the current implementation.

[probert94]

When your app is launched using a deep linkon another app's task, Up transitions users back to your app’s task and through a simulated back stack and not to the app that triggered the deep link. The Back button, however, does take you back to the other app

I have read the link you posted and didn't notice many changes in the concept. The most important difference between up and back, in my opinion, is, that up is contextual, while back navigates through the history.

I agree, that there should be a fallback / default behaviour but as you said it would make sense to let the user customize that component.