Route

Fission

Product

▾

Setup

›

Navigation and overlays

›

Route

Route is one entry inside a Router.

It says, "when the current path looks like this pattern, return this screen." A route does not own navigation state. It is only a matcher plus a small page builder closure. Your app state still owns the current path string, and your reducers still decide when that path changes.

The current implementation keeps route syntax intentionally small and predictable:

•

literal segments such as /settings

•

named parameters such as /users/:id

•

exact segment counts only

There is no built-in wildcard matching, query-string parsing, or browser-history integration here.

Example

use fission::prelude::*;

let selected_project_id = "42".to_owned();
let project_route = Route {
    path: "/projects/:id".into(),
    builder: std::sync::Arc::new(|_ctx, _view, params| {
        ProjectDetail {
            id: params["id"].clone(),
        }
        .into()
    }),
};

If a route needs data from route parameters, use the params value passed to the builder. Keep the closure thin and hand the values into a named screen component.

Field table

Field	Type	Meaning	Notes / default behavior
path	String	Route pattern to match against Router.current_path.	Use literal segments and :name parameter segments.
builder	PageBuilder<S>	Closure that receives build handles plus route parameters and returns the matching screen.	Return a named screen component such as ProjectDetail { id }.

Page contract

The builder returns a normal Widget value. It should describe the screen to display. It should not fetch data, write files, or perform side effects directly.

If the route needs to kick off work, dispatch an explicit action and let the reducer or effect system do that in the right place.

Specific advice

Keep route construction thin. The cleanest pattern is usually to extract a real screen widget and hand any selected identifiers into that widget. That keeps the routing table readable and makes the screen easier to test in isolation.

Also validate parameter parsing locally. Matching /projects/:id only guarantees that there was some text in that segment, not that the text is a valid project id.

Production checklist

For Route, review the fields that change behavior before treating the widget as finished: path, builder. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.

•

If this widget appears inside an interactive flow, keep the surrounding action binding in the parent component and test that the flow still has one clear reducer path.

•

Check the semantics tree for the user-facing label or role that makes this widget understandable without relying only on pixels.

•

Add at least one component or harness test that confirms the visible text, semantic role, action dispatch, and layout constraint that matter for this widget in context.

If a screen starts repeating the same Route setup, extract a named component around this widget. That keeps the reference API small while making product code easier to read and safer for generated code to copy.

Router, RouteParams, and Runtime model.