RouteParams
RouteParams is the type alias Fission uses for the dynamic values captured from a matched route pattern.
Concretely, it is a HashMap<String, String>. When a Router matches a pattern like /projects/:id, it places the dynamic segment into this map so the route builder can read it.
This is intentionally simple. Route parameters are just text. The router does not guess whether :id should be a number, a universally unique identifier (UUID), or a slug. Your route builder parses and validates that value according to your product rules.
Example
use fission::prelude::*;
let builder = |params: &RouteParams| {
let project_id = params
.get("id")
.and_then(|value| value.parse::<u64>().ok());
match project_id {
Some(id) => ProjectScreen { id },
None => ProjectNotFound,
}
};
route_component supplies the same captured map as a build-scoped provider so
a named component does not have to fall back to an anonymous builder:
impl From<ProjectRoute> for Widget {
fn from(_: ProjectRoute) -> Widget {
let params = fission::build::read::<RouteParams>();
ProjectScreen {
id: params.get("id").cloned(),
}
.into()
}
}
The map exists only during conversion of the matched route. Copy the values a
component needs into ordinary widget fields or actions; do not retain a
build-scope handle.
Entry table
Part | Type | Meaning | Notes / default behavior |
|---|---|---|---|
key | String | The parameter name from the route pattern, without the leading :. | For /projects/:id, the key is "id". |
value | String | The raw text from the matched route or path segment. | Always parse or validate before using it as a typed identifier. |
Specific advice
Treat route params as untrusted strings, even in desktop apps. A malformed deep link, an outdated bookmark, or a bug in your own navigation reducer can still put unexpected data here.
Also note what RouteParams does not contain: query strings, hash fragments, or wildcard path tails. The current router only supports exact segment matching with named :param segments.
Production checklist
For RouteParams, review the fields that change behavior before treating the widget as finished: the fields in the table. 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 RouteParams 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.
Related
Route, Router, and State system.