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,
    }
};

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.

Route, Router, and State system.