Skip to main content
A view is a named screen in the app, identified by a URL route. Components and requests nested under a view apply only when that view is active.
name and route are required. url gives the view a representative URL — a concrete address that resolves to it — which tooling uses to navigate to the view (coverage reporting, bulk capture, and probing); a file-level url supplies a default for views that omit their own. description records the view’s purpose, and source links it to a source file. See Schema reference for every field.

​
Route matching

Routes use glob patterns against the URL pathname.
  • * matches exactly one path segment: /users/* matches /users/42, not /users/42/edit.
  • ** matches any depth of segments: /admin/** matches /admin, /admin/users, and /admin/users/42/edit.
  • Literal segments match themselves.
  • Matching is case-sensitive. Query strings and fragments are ignored. Trailing slashes are normalized away before matching.
For requests, Express-style :param segments are normalized to *, so /api/users/:id/orders and /api/users/*/orders are equivalent. See Requests.

​
Most specific wins

When more than one view route matches a URL, the route with the highest specificity score wins. Declaration order breaks ties between routes with equal scores. Specificity is the sum of per-segment scores: The root route / scores 1 — more specific than any wildcard-only pattern. When two routes score equal, the first declared view wins.
/users/admin matches both routes and resolves to UserAdmin. /users/42 matches only UserProfile.
This specificity rule applies only to views. Every matching request applies. See Requests.

​
Scoped vs global

Components and requests can live at the file root or nested inside a view.
  • Global (file root): matched against every view.
  • View-scoped (inside a view): matched only when that view is active.
  • Additive: a view receives its scoped definitions and all globals. A view-scoped $ref subsumes a global component with the same name for that view.
View names should be unique across the sightmap. Runtime behavior is implementation-defined when two files define the same view name. Conforming implementations SHOULD emit a warning.

​
Dependencies

source names the view’s primary file. List supplementary files, such as feature-specific hooks, stores, and CSS modules, under dependencies. Reverse-lookup tools can then associate changes to those files with the view:
dependencies is curation-time metadata. Each string is a project-root-anchored minimatch glob; prefix it with ! to negate it. Runtime consumers MUST NOT add page-load cost based on this field. See the schema reference for usage rules and diagnostics.

​
Next

Components covers selector strings, arrays, and nesting rules. Requests covers method filters and route normalization.