flow
flow copied to clipboard
vaadin
Synchronize rerouteTo, forwardTo and navigate signatures
Describe your motivation
Rough table of which types of parameters are accepted to each method:
| T parameter = target interface HasUrlParameter<T> type | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| class | class + T parameter | class + T parameter + QueryParameters | class + RouteParameters | String | String + QueryParameters | NavigationState | NavigationHandler + NavigationState | String + List<T> locationParams | String + T parameter | |
| navigate | x | x | x | x | x | x | ||||
| forwardTo | x | x | x | x | x | x | x | |||
| rerouteTo | x | x | x | x | x | x | x |
forwardTo, rerouteTo, and navigate are all navigation methods and should therefore be usable consistently unless technically required to behave differently. So if any of them accepts a class as the navigation target, so should the others. If any one of them accepts a String to identify the target, so should the others. Most importantly, since navigate accepts route parameters being part of the location String, forwardTo and rerouteTo should also accept route parameters this way.
Describe the solution you'd like
There should be a better consistency of the signatures of the methods; at the very least, Query Parameters should be supported in every one of them.
Describe alternatives you've considered
Do we actually need three methods for in-app navigation? Could we drop one (or even two) of them?
Do we actually need three methods for in-app navigation? Could we drop one (or even two) of them?
It is a good question, where the answer is most likely yes.
UI#navigate starts complete navigation cycle, and calling UI#navigate while navigation cycle is not complete is not allowed. I.e. you are not supposed to use UI#navigate in beforeEnter for example, you can however call it in afterNavigation as in that stage navigation cycle is complete. Hence rerouteTo/forwardTo is necessary as you want to have have option to divert navigation while cycle is not complete yet. And this comes in two variants, either preserving the url or not. So if reducing number of methods it is theoretically possible to join rerouteTo/forwardTo by introducing additional parameter for url preservation feature. This naturally will be breaking change, which we probably should avoid introducing at this stage.
This ticket/PR has been released with Vaadin 24.2.0.alpha7 and is also targeting the upcoming stable 24.2.0 version.
