In a Vue 3 SSR app, a store created with reactive() at module scope shows one visitor's data to another visitor. Why, and what is Vue's recommended fix?

## Module scope is process scope on the server A common Vue pattern is **shared state in a module**: `export const cart = reactive({ items: [] })`, imported by any component that needs it. In a client-only app this is safe, because the browser evaluates your modules fresh for every page visit, so each visitor gets their own object. On the server, the module system evaluates each module **once** per process and caches it. Every request that imports `store.ts` receives the same object. The object is a **singleton** for the lifetime of the server, and the Vue SSR guide names the resulting bug **cross-request state pollution**: data specific to one user, mutated into shared state, leaks into a response for another user. ## How it shows up - One visitor's name, cart or permissions appear in another visitor's HTML. - Lists grow across requests because each render appends to the same array. - Memory climbs steadily because per-user data is never released. - It is intermittent: it depends on traffic and timing, so a single developer clicking through locally rarely sees it. ## Why resetting the singleton is not a fix Renders are asynchronous: `onServerPrefetch` callbacks await network calls, and while one request waits, the server handles another. A typical interleaving: 1. Request A sets `store.user = 'A'` and awaits a fetch. 2. Request B arrives, resets the store and sets `store.user = 'B'`. 3. Request A resumes and renders its page with user B. The only reliable fix is that no two requests ever hold the same object. ## The recommended fix: an app per request The Vue SSR guide recommends creating a new instance of the entire application, including the router and global stores, on each request, and sharing state through **app-level provide** rather than direct imports: 1. Put app creation in a universal factory function, for example `createApp()` in `app.ts`. 2. Inside it, call `createSSRApp`, create each store, and register it with `app.provide(key, store)`. 3. Components read it with `inject(key)` instead of importing a module-level object. 4. The server handler calls the factory for every request; the client calls it once on page load. 5. The factory returns the store too, so the server can serialize its state for hydration. ```ts import { createSSRApp, reactive, type InjectionKey } from 'vue' import App from './App.vue' export interface Cart { items: string[] } export const cartKey: InjectionKey<Cart> = Symbol('cart') export function createApp() { const app = createSSRApp(App) const cart = reactive<Cart>({ items: [] }) // one per request app.provide(cartKey, cart) return { app, cart } } ``` Re-evaluating every module per request would also isolate requests, but the guide rejects it: initialising modules is costly and would hurt server performance. ## Where state can live | Location | In the browser | On the server | Safe for per-user data? | |---|---|---|---| | Module scope | once per page visit | once per process | no | | App-level `provide` from a per-request factory | once per page visit | once per request | yes | | Component state in setup | per instance | per instance, per render | yes | ## Proving the fix 1. Put a deliberately slow data source behind the page so renders overlap. 2. Fire concurrent requests authenticated as two different users. 3. Assert that each response contains only its own user's markers. 4. Keep it running for a while and watch process memory: per-request state should be released when each request ends. A single sequential request per user never exercises the interleaving case, which is why this bug usually surfaces only in production traffic. ## What else counts as module-level state - Composables that declare their `ref`s outside the exported function, deliberately sharing them. - Caches keyed by something other than the request, and plain `let currentUser` variables. - A router or other instance created at module scope instead of inside the factory. - Third-party libraries that keep their own singletons. Immutable configuration and pure helper functions are fine at module scope. Store libraries designed for SSR follow the same per-request rule.