Blazor Data and State

Requirement A component MUST invoke an Application handler carrying a Command or Query role suffix rather than compose Domain calls or write storage.

Rationale The handler is the one place a use case exists, so a component composing its own sequence creates a second definition.

Requirement A specification introducing state MUST classify it as durable, device-local, or derived.

Rationale Durable state is persisted, versioned, and exported. Device-local state is persisted but excluded from export. Derived state is computed from durable state and never persisted.

Requirement Persisted state MUST load once during startup into a typed store that components read from.

Rationale A component reading storage on render turns every frame into an input-output call. A route renders its loading state until the store finishes loading.

Requirement A derived value MUST be computed in one place in Domain or Application and consumed everywhere else.

Rationale Recomputing the same value in a component is a defect even when the result currently matches.

Requirement Input validation MUST run in an Application validator returning a typed result.

Rationale A form renders those results rather than restating the rules. A browser-side convenience check improves feedback but cannot be the only enforcement. This realizes litespec/frontend/data#validate-a-form-with-the-generated-schema.

Requirement An Application handler MUST return a typed result union covering success and each named failure.

Rationale Signaling failure through null, an empty collection, or a bare boolean forces every caller to guess which failure occurred. This realizes litespec/frontend/data#map-every-failure-to-one-problem-type.