08-state-management

You separate client state from server-fetched data by keeping remote data in resource/query layers and restricting global stores to UI and session state. This prevents global state from becoming a disorganized dumping ground.

The best way to structure global stores is to split them by concern, creating narrow stores for auth, theme, and feature UI state. This ensures state remains small, explicit, and framework-appropriate across multi-page apps.

Global state becomes a dumping ground when server cache mixes with UI state. Applying resource/query patterns for remote data isolates server fetches, keeping client state small, explicit, and focused on session or feature data.

To hydrate frontend state intentionally, define explicit hydration rules from verified safe sources and document persistence rules. This ensures state initialization remains controlled and secure across multi-page applications.

You should use actionable mutations instead of raw writes whenever managing shared UI or feature data. This enforces clear intent and traceability, preventing uncontrolled modifications to narrow, concern-focused client stores.

Yes, this approach is designed for teams adopting resource/query patterns for remote data. It explicitly isolates server cache from UI state, satisfying requirements for server data isolation and narrow stores per concern in multi-page apps.