IDB State Persistence Architecture

Philosophy

Local Database First: IndexedDB (IDB) is the primary source of truth for all application state. Every user interaction that changes state MUST persist to IDB immediately to survive navigation, page refreshes, and session restarts.

This architecture treats IDB as a local database, not a cache. State lives in IDB first, components read from it, and all mutations write through to IDB synchronously (no debouncing or batching by default).

Why IDB over localStorage:

• Structured data storage (objects, arrays, not just strings)
• Indexed queries for efficient retrieval
• Larger storage limits (hundreds of MB vs 5-10 MB)
• Async API that doesn't block main thread

Relationship with Other Skills:

• javascript: Provides error handling (Rule 1), timeout patterns (Rule 2), cleanup (Rule 4)
• web-components: Components subscribe to IDB state changes via event listeners
• Integration: State Managers act as the bridge between IDB and UI components