Qwik useStore serialization boundaries for non-POJO state

Resumability and State Serialization

Qwik's resumability model depends on serializing the application state into HTML to avoid traditional hydration. This process requires that data managed via useStore or useSignal be fully serializable to ensure a seamless transition from server-side rendering (SSR) to client-side execution.

Production State Consistency

While local development environments may handle certain object structures flexibly, production builds utilize an optimizer that aggressively splits code into lazy-loadable chunks. When complex objects—such as class instances or objects containing non-serializable methods—are passed into useStore, the state may not persist across the server-client boundary.

There is a need to define the exact boundary for what constitutes a serializable object in production to prevent state loss during interaction.

• Which specific data types are stripped during the serialization process in a production build?
• Is there a documented mechanism to mark specific non-serializable properties for exclusion without breaking the store's reactivity?