Reconsider the roles of Router, RouteUtil and RouteRegistry as routes can now be added dynamically

As it is now possible to register routes dynamically to RouteRegistry, we should reconsider the overall design of the router and its concepts. Currently there are several classes with public API for users and those classes might also contain some internal (but public) API. It is not that clear that what is handled by which part. The classes in question:

• Router
  • getUrl(...) methods which are for application developers to resolve the url for certain navigation target
  • internal static resolve(...) for handling the convention of
    • Main / MainView -> ""
    • AdminView -> "/admin"
  • bunch of internal methods
  • the router is accessed by end user via UI.getCurrent().getRouter()
• RouteRegistry
  • contains the registered routes, for internal usage
  • currently has the low-level API for adding and removing routes
  • accessed via static methods in SessionRouteRegistry and ApplicationRouteRegistry where former requires the session as a parameter and latter requires servlet context
  • currently accessing and using the registry is quite inconvenient and not meant for application developer facing API
• RouteUtil
  • only static methods
  • helpers for handling all route related annotations
  • mostly internal usage and inside .internal package, but someone might use these for some reason (?)

The current setup is a bit confusing due to:

• Router mixing both internal and public API
• The route registries don’t have all the convenience methods one would expect to find there for registering routes dynamically
• RouteUtil has another setRoute, setAnnotatedRoute and setNavigationTargets that also allow registering routes to given route registry
• There should be an easy facade for adding and removing the routes and it is the only thing you should need to know as an application developer, and it should be easily accessible

The current WIP demo and tutorial for registering routes dynamically: https://reviewable.io/reviews/vaadin/flow-and-components-documentation/362#- https://reviewable.io/reviews/vaadin/flow-demo/463#-

EDIT: Also one should consider the future - as in at some point some of the routes might be registered on the client side using Vaadin Router which is its own concept already. Thus we will have Vaadin Router and Flow router separately.

[heruan]

I understand, thank you for clarifying. Note that the add-on does not permit to have parameterized router layouts, it just covers an aesthetic aspect of the issue; I hope the official implementation will eventually cover also router layouts (as I described in the other issue, so let’s follow up there).

[pleku]

Added #4890 #4891 #4892 to the V13 scope.

We did consider the parameterized router layouts, and also what it would mean to allow plug-in dynamic route resolvers in addition to our own default route resolver. That is to be continued in #3467 and has to consider that we want to add #2740 too