Vue Storefront 2.10+ Cache Key Divergence Between SSR and Client Hydration with Custom Queries

Context

Vue Storefront 2.10+ composables such as useProduct and useCategory cache responses in Pinia stores keyed by normalized parameters. During SSR, the @vue-storefront/nuxt module serializes Pinia state, but client-side hydration recomputes cache keys using runtime parameters—including locale, currency, and custom headers—that may not match the SSR context.

Problem

When a composable is invoked with a customQuery object (e.g., { fields: 'minimal' }), the server and client each create a distinct cache key because the object reference differs between renders. The SSR-rendered payload is stored under the server-side key, while the client composable initializes a new entry under a different key, leaving stale data in the client cache until manual invalidation or TTL expiry.

Constraints

No built-in composable option forces cache-key alignment between SSR and client. Workarounds include disabling SSR for affected routes (sacrificing SEO), implementing a custom cache-key serializer, or calling load() with identical parameters in onMounted. The core team has not yet standardized a deterministic serialization protocol (e.g., sorted-key JSON.stringify) or exposed a hydration hook to reconcile Pinia state before composable initialization.

What deterministic cache-key serialization strategy would guarantee identical keys across SSR and client without requiring developer intervention? Should Vue Storefront introduce a hydration lifecycle hook that allows Pinia cache reconciliation before composables read state? Are there middleware-level header differences that further destabilize key parity beyond customQuery object references?