Client State Management
Pathrule1 Rule • 2 Memories
Client state management is an ownership problem before it is a library choice. This bundle classifies URL, form, component, shared client, and server state; keeps one source of truth; derives redundant values; and defines persistence boundaries. Unlike TanStack Query, it decides where every state category belongs while the existing pattern specializes in remote data caching and synchronization.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
Rules
1Store each fact once and derive the rest/src/statehighstrictEvery state value has one authoritative owner, update path, reset event, and persistence policy.
| 1 | Every state value has one authoritative owner, update path, reset event, and persistence policy. Duplicated and contradictory fields create impossible states such as selected objects no longer present in the latest list or loading flags that outlive the request. Enforce this boundary in /src/state so invalid work stops before it reaches another subsystem or creates an externally visible side effect. |
| 2 | |
| 3 | - Classify state before choosing a store: server resource, URL navigation, form draft, local interaction, cross-screen client state, or derived view. |
| 4 | - Keep server resources in the server-state layer and store stable identifiers in client state instead of copying full records. |
| 5 | - Derive filtered lists, totals, validation, selection objects, and status flags from authoritative inputs unless measured performance requires memoization. |
| 6 | - Define reset behavior for logout, tenant switch, route exit, successful submit, cancel, and schema version change. |
| 7 | |
| 8 | Verification: Exercise each ownership transition and intentionally update one source while another is stale; confirm the model cannot represent contradictory or cross-identity state. |
Memories
2Persistence is a migration commitment/src/statePutting state in local storage, IndexedDB, or a native store means old schemas and prior identities can reappear after new code ships.
| 1 | Putting state in local storage, IndexedDB, or a native store means old schemas and prior identities can reappear after new code ships. Persist only values whose user benefit survives reload, and include schema version, owning identity, tenant, created time, and expiry where relevant. |
| 2 | |
| 3 | Migrate or discard incompatible versions explicitly instead of catching parse errors and keeping partial state. Clear identity-scoped data before another user or tenant can render. Never persist credentials or sensitive server records merely to avoid a refetch. Keep the decision explicit at /src/state; moving it into an incidental caller makes behavior depend on which route happened to execute first. |
| 4 | |
| 5 | See /src/routes for shareable state and the authentication pattern for identity transitions. That related boundary consumes this decision and carries the evidence that proves it still holds. |
Why this pattern
Agents copy props into local state, mirror server cache into a global store, and persist transient UI flags, creating contradictions and unclear reset behavior.
Built for Frontend teams choosing ownership and lifecycle for interactive application state.
Keeps your assistant from:
- The same value stored in props, local state, and a global store
- Server data copied into client state with no synchronization contract
- Transient UI state restored after its owning screen or identity changed
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-08-25