Flow: Add API for dynamically registering routes

Created on 17 Apr 2018  路  11Comments  路  Source: vaadin/flow

This feature would make it possible to have a separate module/dependency dynamically adding a route for instance in an init listener.

Epic enhancement routing website

Most helpful comment

Our use case would be to allow user to define their won layout class, and store in the configuration table in the database. When rendering the page, we need to retrieve the layout definition defined by users and programmatically set that layout class as the routelayout of the designated page. Therefore APIs/methods to programmatically register routelayout would be essential to us.

All 11 comments

It would be great to also have support for adding parameterized routes dynamically; this would for example allow us to have jax-rs-like urls such as /person/{id}/add

My use case would also benefit from dynamically registered routes: I create views dynamically on start-up of application depending on a configuration loaded. Configured parameter is arbritrary and not known in advance. Therefor, I cannot declare routes at coding/compile time.

My current workaround is real hack: Building classes at runtime using Javassist with required annotations. Unfortunately, it wasn't enough to register these generated classes as spring beans. Instead I had to hook into VaadinServletContextInitializer and RouteServletContextListener to make them available to Vaadin.

We also need the possibility to create routes dynamically during runtime.

Our Vaadin application (currently Vaadin 8) is very modular and allows adding, removing, activating and deactivating modules at runtime. Modules may even be added and removed without application restart (achieved by embedding an OSGI runtime that picks up new jars).
Modules can register views but those views are only really available, if the module is actually activated by the user.
Currently we use a custom ViewProvider that only provides views of present and active modules.
Since arbitrary new modules may be deployed at runtime it is also not possible to know views / routes beforehand.

Of course we could put checks into each view / route but we would rather have that logic in one central place. Modules may be developed by third party developers and we don't want to rely on their implementation. So a custom route registry would be ideal for us.

There are two different technical approaches for being able to change the routing configuration while the application is running:

  1. Allow modifying the contents of the current route registry.
  2. Make the route resolving logic pluggable instead of only looking up routes from a static registry.

@markus-herrmann, @steffen-harbich-itc: Do you see any reasons for why either approach would be more suitable in your particular cases?

Hi Legioth,

in my opinion allowing the content of the route registry to be modified would probably be easier to use and also easier to implement . All we would need is a "registerRoute" and "unregisterRoute" method on the registry (or returning a Registration object from the "registerRoute" method that can be canceled instead of an "unregisterRoute" method).

The current RouteRegistryInitializer could remain, discover Routes defined with annotations and also use the "registerRoute"-Method on the registry to register those discovered routes.
This way we can mix static Routes (by annotation) and additional dynamic Routes.

@Legioth, approach 1 would be sufficient for my scenario and probably easier.

Our use case would be to allow user to define their won layout class, and store in the configuration table in the database. When rendering the page, we need to retrieve the layout definition defined by users and programmatically set that layout class as the routelayout of the designated page. Therefore APIs/methods to programmatically register routelayout would be essential to us.

Acceptance Criteria

  • Use cases:

    • _When deploying an app, I want to configure the routes for it dynamically, because the routes depend on a deployment configuration and I don't want to change the app code for this_
    • _When building an app, I want to dynamically add/remove routes, because business data has changed and available views are changed also (eg. subscription created/expired)_
    • _When building an OSGi app with Flow, I want to dynamically add/remove new bundles that add/remove new routes to an existing running Flow web application, so that I can build modular web apps with Flow and OSGi_
  • There is a demo in flow-demos for this particular feature.

  • There is a new tutorial about _Registering routes dynamically_ that shows use usage of this API
  • There is a new tutorial about _Adding and removing routes from OSGi bundles_ that shows use usage of this API

Tried that new feature and replaced my workaround with the dynamic routes. Worked like a charm, and great documentation. Good job!

Links to the demo and tutorials would be useful

Was this page helpful?
0 / 5 - 0 ratings

Related issues

joheriks picture joheriks  路  4Comments

pleku picture pleku  路  4Comments

SomeoneToIgnore picture SomeoneToIgnore  路  4Comments

anezthes picture anezthes  路  4Comments

pleku picture pleku  路  4Comments