Load a resource after matching its URL

Navigation is not data availability

Matching /books/42 proves that the URI fits a route template. It does not prove that book 42 exists, that the network is available, or that the current account may read it.

Keep the request lifecycle stable

Resolve the identifier at the screen boundary. Use your normal state-management or repository layer to load it, and avoid creating a new request on every widget rebuild. When the identifier changes, cancel or disregard an obsolete request so late results do not overwrite a newer screen.

Design four outcomes

Show a loading state, a useful missing-resource state, a recoverable error, and the loaded content. Authentication and authorization failures need deliberate handling rather than a generic empty page.

Make deep links self-sufficient

A route should be able to reconstruct the screen from its URI. Passing a previously loaded object through extra can be an optimization, but it should not be the only way to display a resource after a fresh entry or reload.

GoRoute(
  path: '/books/:bookId',
  builder: (_, state) => BookScreen(
    id: state.pathParameters['bookId']!,
  ),
);
// BookScreen owns loading/error/missing/ready states.
// Its repository fetches data using the validated ID.