Should Qwik automatically persist useStore state across page reloads?

Answer

No. Qwik should not automatically persist useStore state to durable storage across full page reloads by default. The default should remain resumability via serialized state in the DOM, with zero durable I/O, and persistence to localStorage or IndexedDB should be opt-in per store.

Established behavior (Qwik 1.x)

• Qwik serializes useStore state into the server-rendered DOM and restores it when the application resumes. This enables resumability across client navigation without re-executing side effects.
• That serialized state lives in the HTML for the current request only. On a full page reload the HTML is regenerated, so useStore state resets to the server-rendered initial value unless the developer saves it elsewhere.
• Automatic persistence to durable storage is not part of Qwik core today. useStore is reconstructed from the HTML on resume and is discarded on reload.

Likely explanation and trade-offs

Automatic persistence would change Qwik's core promise of lightweight, zero-IO startup. It would require reading persisted data before or during resume and writing on every state change, adding serialization cost and main-thread work.

An opt-in flag to persist a specific store to localStorage or IndexedDB after resume preserves the default lightweight model while allowing richer UX when desired. That is the more consistent design.

Performance impact

• Page load: reading from localStorage is synchronous and blocks the main thread. For large stores this adds measurable startup latency and memory pressure from parsing JSON.
• Runtime: writing on every mutation adds serialization cost and storage I/O. localStorage has size quotas and throws on quota errors. IndexedDB avoids sync jank but adds async complexity.
• HTML size: resumability already adds payload weight to the document. Adding durable persistence does not reduce HTML size; it adds a second storage path.

SSR and hydration interaction

Server rendering has no knowledge of client durable storage. If persisted state is applied unconditionally, the live DOM diverges from both the server-rendered markup and the serialized snapshot Qwik resumes from, so a reconcile step is unavoidable: either re-render after reading storage, or treat persisted data as a post-resume patch.

Both approaches risk flicker, version skew across deploys, and failures for non-serializable values. Serialization of arbitrary store shapes can fail and complicates store schema versioning.

Verification steps for this case

1. Create a minimal Qwik app with a useStore and mutate it client-side. Observe that state survives client navigation but resets on a hard reload.
2. Inspect the server-rendered HTML for the serialized state payload that carries the store snapshot.
3. Confirm no durable read occurs on resume by watching storage access in devtools.

Assumption: Qwik 1.x behavior as described in the question. Current verification is recommended because Qwik evolves quickly and any RFC or utility for store persistence may change.