Store-Free Shared State

## The problem it solves Some state is needed by components that are far apart in the tree. A **notification queue** is a typical case: - a form deep inside a page adds "Saved" or "Upload failed"; - a toast list mounted in the layout renders the messages; - a badge in the header shows how many are unread. Passing the queue down as props and bubbling additions up as events through every intermediate component is tedious and couples components that do not care about notifications. ## Why a plain module works in Vue 3 Vue's reactivity is **decoupled from the component model**. `reactive()`, `ref()` and `computed()` can be called anywhere, not only inside `setup()`. Two facts combine: 1. An ES module is evaluated **once**; every `import` receives the same exported binding. 2. A component that reads a reactive value during render (or in a `computed` it renders) tracks it, wherever that value was created. So a reactive object created at module scope is a **singleton** shared by every importer, and every reader updates when it changes. ```ts // notifications.ts import { reactive } from 'vue' export const notifications = reactive({ items: [] as { id: number; text: string }[] }) ``` ```vue <!-- ToastList.vue --> <script setup lang="ts"> import { notifications } from './notifications' </script> <template> <ul> <li v-for="n in notifications.items" :key="n.id">{{ n.text }}</li> </ul> </template> ``` Any other component can import `notifications` and push to `notifications.items`; the toast list and the header badge both update. ## reactive() or ref() for the store | Choice | Access | Notes | |---|---|---| | `reactive({ items: [] })` | `store.items` | groups several fields; do not reassign the whole object | | `ref([])` | `items.value` in script | fine for a single value; can be replaced wholesale | | `computed()` at module scope | `unread.value` | derived store value shared by all importers | Both are fine. The Vue docs use a single `reactive()` object for the store example and note that `ref()` and `computed()` can be shared the same way. ## What you get, and what you do not What the pattern gives you: - a single source of truth with no library and no setup; - fine-grained updates: only components that read the queue re-render; - plain TypeScript types, since the store is just an object. What it does **not** give you by itself: - **Controlled mutation.** Every importer can write anything. The Vue docs recommend putting intention-revealing actions next to the state; exporting a `readonly()` view makes the rule enforceable. - **Isolation between requests under SSR.** On a server, modules are initialised once per process, so the singleton is shared by all users. This is called cross-request state pollution. - **Tooling.** Devtools inspection of the store, hot-module replacement that keeps its state, and plugin hooks are what store libraries add. ## Where it fits The pattern is a good fit for client-only apps and for small slices of shared state: a notification queue, a theme preference, a feature flag cache. It is also a good first step: if the app later adopts a store library, the state and action functions move over with little change, because the shape (state plus actions) is the same. ## Testing a module store Module state lives as long as the module does, which affects tests: - Tests that run in the same module registry share the store, so a notification pushed in one test is still there in the next. - Export a `reset()` action (or a factory used by the module) so each test can start clean. - Prefer asserting through the store's actions and the rendered output rather than poking at internal fields. ## Common mistakes - Calling a method defined on the store object without its receiver (passing `store.dismiss` as a bare callback), so `this` is lost; the docs call `store.increment()` with the parentheses for this reason. - Letting every component write to the store directly, so when a bad value appears nobody can tell which importer wrote it. - Creating the reactive object **inside** a function that each component calls, which gives each caller its own copy and nothing is shared.