Frontend Rendering and Routes

Requirement A route MUST load each read it needs through one shared cache before its view renders.

Rationale The page then renders with its data rather than showing a spinner after it appears. The cache owns freshness, so the router never holds a second copy.

Example An entity route loads its record and every read the record's own sections need.

Requirement A view MUST read route data through the same cache entry its route filled.

Rationale A read naming another key issues a second request, and the two answers can disagree. A failed read reaches the route's error boundary, which draws the shared problem state.

Requirement A route MUST declare its address parameters in a validated schema, including its filters and its page.

Rationale A filtered list is then a link somebody can share, bookmark, and reopen. A filter in component state reaches nobody and is lost on the first navigation away.

Example The list schema declares its own text field and spreads the shared paging fields.

Requirement A frontend MUST load each route and each language as its own download, with no icon set or language loaded whole.

Rationale A signed-in user opens one address and reads one language. A reader in Dutch who never leaves the dashboard should not download English.

Example A dictionary loader returns one language. Each route file or folder ships as its own download.

Requirement A frontend MUST prefetch the route the reader signals intent toward, without treating that prefetch as a cache beyond the shared cache.

Rationale Most navigations then render from the cache the routes already fill. A router caching a second time serves a stale answer beside a fresh one.

Requirement A data-driven route MUST define its loading, empty, error, forbidden, not-found, and ready behavior.

Rationale A blank region while a request is pending or failed gives the reader no signal at all. The root not-found handling draws the shared outcome page.

These six are the states a route has. A control adds disabled and pending under litespec/frontend/components#render-complete-states, because both describe a control rather than a route. A route adds not-found, which a control does not, because a missing target resolves at the route.

Requirement Actor-specific data MUST declare its cache key, partition, invalidation owner, and security review before caching, beside the read definition setting the key.

Rationale Shared route behavior otherwise serves one actor's data to another. An uncached read is the safe default, and a cache partitioned per request is the safe server shape.

Requirement A development or edge proxy rule MUST route only, and never decide who the actor is or what the actor may read.

Rationale The proxy runs before the request reaches the API, so it cannot see the resource authorization depends on.

Example A development proxy forwards /api and /auth to the API and changes nothing else.

Requirement A server-rendered frontend MUST construct its data cache inside each request.

Rationale Two readers served at the same time must not read each other's data. A cache outliving one request would serve the next reader the previous reader's answer.