Navigation
Keep the host router in control while Varendo preserves selection and back context across adaptive views.
Navigation is a host adapter, not a workflow engine. A view may request a registered route; your app owns the URL, guards, history, and loading.
When you need this#
- A row, link, or breadcrumb in a view should open one of your app's routes.
- Back and forward must restore the same region state.
- A wide master-detail view that splits into list plus detail must keep its context.
1. Declare the routes#
Navigation targets are versioned references, not free URLs. A view may request only the routes its manifest declares, and only when the session holds the navigation.propose grant. Unknown or undeclared destinations are rejected before your router sees them.
2. Map requests to your router#
Write a small adapter that translates a requested route into your router's calls:
navigation.ts
const navigation = {
open: ({ resourceId, identity }) => router.push(resourceRoute(resourceId, identity)),
back: () => router.back(),
};
router is your app's router. The adapter decides whether to follow the request — it can refuse unknown or unauthorized destinations.
3. Preserve context across layouts#
A wide master-detail view may become a list then a detail on a narrow container. The selected identity, filter, scroll position, and a discoverable Back action must survive that change.
- Back and forward restore the equivalent region state.
- Unknown or unauthorized destinations are rejected by the host.
- A route change cancels obsolete evaluation and renderer loading.
- Focus moves to the new page or detail heading and returns predictably.
What can go wrong#
- A request for a route the manifest does not declare is rejected — no navigation happens.
- Revoked access during a pending navigation fences the request; do not navigate to stale data.
- A route change must cancel in-flight evaluation, or a late result can commit into the wrong screen.