Overview¶
Routing lets you configure URL paths to allow your users to navigate to specific parts and states of your app directly through their browser's address bar.
In general, this brings your app closer to a regular web page in terms of usage standards. For example, this can be useful for letting users bookmark specific parts of your app, or enabling usage of the back and forward buttons to navigate throughout your app.
Routing Basics¶
A route is an object with, among other attributes, a URL path, and a form to open when navigating to this route.
As an app developer, you will need to define routes for your app. When the URL changes, the router will look for a matching route. The ultimate goal is to open the form associated with the given URL.
The router will attempt to match routes in the order they are defined.
When a route is found, the router will call the route's before_load
method.
If the before_load
method raises a Redirect
, the router will navigate to the redirected URL.
If the route has a load_data
method, it will be called, and the return value will be available as the data
property on the RoutingContext
.
Once the load_data
method has been called, the router will call the route's load_form
method. A routing_context
will be passed to this method. By default, the load_form
method will call anvil.open_form
on the matching route's form, with routing_context
passed as a keyword argument.
Caching¶
There are two types of caching: form caching and data caching.
If a form is cached, instead of creating a new instance, the router will call the route's load_form
method with the cached form instance.
If data is cached, the router will only call the load_data
method if the data is stale. See the Caching section for more details.
Server vs Client Routing¶
Should the user open the app directly through a URL as their initial page request, the routing process will occur entirely on the server. Otherwise, if the user is navigating from within the app, the process occurs on the client.