Frontend Rendering and Routes

A view that renders before its reads complete shows a spinner after it appears, then swaps the spinner for content: two drawings for one navigation, with layout shifting between them. Loading each read through one shared cache before the view renders gives the page its data in place. The cache owns freshness, so the router keeps no second copy that could disagree.

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

Reviewed forWhich routes render before their reads load through the one shared cache? Look in the route loaders and the cache definitions.

Marked guidance: a reviewer answers this question.

A view that reads under another key issues a second request for data the route already loaded, and the two answers can disagree when the data changes between them. Reading through the same cache entry the route filled renders the data the route approved. A failed read reaches the route's error boundary, which draws the shared problem state instead of a half-rendered view.

Reviewed forWhich views read under another key than the cache entry their route filled, or handle a failed read outside the route error boundary? Look in the view data reads and the route loaders.

Marked guidance: a reviewer answers this question.

A validated schema makes the address the whole input: a filtered list is a link somebody can share, bookmark, and reopen, and opening it restores the same filters and page. Validation also refuses a malformed address at the boundary instead of rendering a page from nonsense values. A filter kept in component state reaches nobody and is lost on the first navigation away.

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

Reviewed forWhich routes leave address parameters, filters, or page outside a validated schema? Look in the route parameter schemas.

Marked guidance: a reviewer answers this question.

A reader opens one address and reads one language, so downloading every route and every language up front wastes the reader's time on code and copy outside what they read. Each route and each language ships as its own download: a reader in Dutch who stays on the dashboard downloads neither English nor the routes outside their path. No icon set or language loads whole for the same reason.

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

Reviewed forWhich routes or languages ship in a shared download, or load an icon set or language whole? Look in the route bundles and the dictionary loader.

Marked guidance: a reviewer answers this question.

When the reader signals intent toward a route, by hovering a link or focusing a menu item, prefetching loads that route's data into the shared cache before the navigation starts, so most navigations render from data already in place. The prefetch fills the shared cache only: a router that kept its own second cache would serve a stale answer beside the fresh one.

Reviewed forWhich route prefetches land outside the shared cache, or feed a second router cache? Look in the router prefetch wiring.

Marked guidance: a reviewer answers this question.

A blank region while a request is pending or failed gives the reader no signal: they read no difference between loading and broken. Defining loading, empty, error, forbidden, not-found, and ready behavior gives each state a designed drawing, and the root not-found handling draws the shared outcome page for an absent address.

These six are the states a route has. A control adds disabled and pending under litespec/frontend/components#render-control-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.

Reviewed forWhich data-driven routes miss a loading, empty, error, forbidden, not-found, or ready behavior, or leave an absent address outside the shared outcome page? Look in the route state definitions.

Marked guidance: a reviewer answers this question.

A cache entry that ignores whose data it holds serves one actor's answer to another reader: the classic leak behind a shared cache. Declaring the cache key, the partition, the invalidation owner, and the security review beside the read definition forces each cached actor-specific read to name its boundary before it caches. An uncached read is the safe default, and a cache partitioned per request is the safe server shape.

Reviewed forWhich cached actor-specific reads lack a declared cache key, partition, invalidation owner, or security review beside the read definition? Look in the read definitions setting cache keys.

Marked guidance: a reviewer answers this question.

A development or edge proxy runs before the request reaches the API, with no view of the record or the permissions an authorization decision depends on. A proxy rule that decided who the actor is or what the actor may read would enforce a different boundary than the API, and the two would disagree on the first edge case. The proxy routes and nothing else; the API owns identity and authorization.

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

Reviewed forWhich proxy rules decide identity or authorization instead of routing only? Look in the proxy rules.

Marked guidance: a reviewer answers this question.

A server renders for many readers at once. A data cache shared across requests serves the next reader the previous reader's answer, leaking one actor's data to another with no error to report it. Constructing the cache inside each request gives every reader a fresh cache that dies with the response.

Reviewed forWhich server rendering reuses a data cache across requests instead of constructing it inside each request? Look in the server request setup.

Marked guidance: a reviewer answers this question.