Askr
Routing & Data

Paths, Parameters, and Destinations

Use paths, parameters, and destinations with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use paths, parameters, and destinations

Declare typed path parameters in the route and accept them as page props; construct destinations through the route reference.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep paths, parameters, and destinations configuration next to the component, route, or server composition root that owns it.
  3. Handle pending, unavailable, cancellation, and failure states, then verify the production path.
const projectRoute = route('/projects/:projectId', ProjectPage);

function ProjectPage({ projectId }: { projectId: string }) {
  return <Project id={projectId} />;
}

const destination = to(projectRoute, { projectId: project.id });

Static and dynamic segments

Askr parses each path into `ParsedSegment` entries tagged as `static` (a literal like `users`), `param` (a `{name}` capture), `wildcard` (a bare `*` matching exactly one segment), `splat` (`{*name}`, capturing the rest of the path into one named param), or `catchall` (a trailing `/*`). This parsing happens once when the route is registered, not on every navigation, and the resulting segment list is what route ranking and matching both run against. Mixing kinds is normal — `/files/{*path}` combines a static prefix with a splat to capture an arbitrarily deep file path in a single param.

Typed parameters

`RoutePathParams<Path>` is a template-literal type that extracts param names straight from the path string, so `route('/teams/{teamId}/members/{memberId}', ...)` gives your component a `{ teamId: string; memberId: string }` prop type without you declaring it separately. If a component you're wiring up already has its own prop shape, Askr checks compatibility for you via `CompatibleRouteComponent`, so a mismatched param name fails at the `route()` call site rather than silently passing `undefined` at runtime. All path params come through as strings — parsing a numeric ID or a date out of one is on you, same as reading `location.search`.

Route destinations

Building a link target from a typed route uses `to(routeRef, params, search?)`, which returns a `RouteDestination` — just `{ href: string }` — built from the `RouteRef` that `route()` returned when the route was declared. Because the `RouteRef` carries its param and search types, passing the wrong param name or an invalid search key is a type error before it's a broken link. Pass that `RouteDestination` to `Link`'s `to` prop, or to `navigate()`, instead of hand-assembling a URL string with template literals.

Not found behavior

When `resolveRouteRequest()` can't match a path against any registered route, it returns `null`, and it's the caller's job to fall back to the registered `fallback()` component for that case. A policy can also produce a 404 deliberately by returning `notFound()`, which is a `deny(404)` decision — useful for routes like `/posts/{slug}` where the segment matches syntactically but the slug doesn't correspond to a real post. Both paths end up rendering the same fallback UI, but only the policy-driven one runs after your loader has had a chance to check the data.