Store Plugins and Devtools

Observe store changes deliberately

Pinia exposes store subscriptions and action hooks for behavior such as persistence, audit events, or timing. $subscribe observes state mutations and can be configured to run synchronously or after a patch. $onAction observes action invocation and completion, including async outcomes. These hooks are powerful cross-cutting points, but they can create duplicate work or leak subscriptions if their lifetime is unclear.

A plugin can augment stores when installed on the Pinia instance. It can add a method, subscribe to changes, or initialize state. Plugins should be narrow and predictable; a persistence plugin that serializes every field can accidentally store access tokens or large server responses. Use an allowlist of safe fields, validate persisted data when loading, and define reset behavior on logout or schema changes.

Devtools and debugging

Vue Devtools can show stores, state, getters, and action history during development. Named actions make the timeline easier to read than many unnamed direct mutations. Inspect state transitions and payloads without logging secrets. Devtools are a development aid, not a production audit system or authorization boundary.

Time-travel or mutation inspection depends on mutations being represented clearly. A large direct object mutation may be harder to reason about than a named action or explicit $patch. Use patches when a group of fields should change atomically from the observer's perspective. Avoid wrapping every single assignment in boilerplate; the goal is useful traceability.

Subscription lifetime

Store subscriptions can outlive a component if registered as detached. That is appropriate for an app-level persistence or telemetry service, but the app must stop it during teardown or identity change. Component-owned subscriptions should be removed when the component ends. Keep the unsubscribe function and call it in scope cleanup. Otherwise route visits can accumulate listeners that write duplicate storage entries or emit repeated telemetry.

Action hooks should avoid changing core state invisibly. They can record duration, success, or failure, but should not implement hidden business transitions that make behavior depend on plugin order. If a plugin fails, decide whether it blocks app startup or degrades gracefully. Persistence failure should not necessarily prevent a user from interacting with an in-memory store.

SSR, persistence, and sensitive data

Persist only fields that should survive refresh. Browser storage is user-accessible and mutable; never treat it as trusted authorization state. Version the persisted schema, validate values, and handle corrupt or old data safely. Clear user-scoped data on logout and ensure the key is scoped by the right account or tenant.

For SSR, a plugin must be installed on each request's Pinia instance and must not retain request state in a module singleton. Do not write server user data to shared browser storage during rendering. Test two app instances to verify no state or subscription is shared unintentionally.

Plugins and devtools improve observability when ownership and data policy are explicit. A plugin should make the store easier to inspect or integrate, not create a hidden second source of truth.

Use $subscribe's detached option only when the subscription intentionally outlives the component, and assign that longer lifetime to an app-level owner.

Persist only safe preferences

Create a Pinia plugin that persists a theme preference and locale, but not the entire user store. Use an allowlist of fields and a versioned storage key. On initialization, parse stored data inside a try/catch, validate allowed values, and fall back to defaults if the data is malformed. On logout, clear any account-specific state and keys. Do not persist tokens, permission claims, or server responses in generic localStorage.

Register a $subscribe callback to write changes, and keep its unsubscribe handle at app scope. Avoid serializing after every tiny mutation if a patch groups multiple updates. If writes are expensive, debounce them and flush on a deliberate lifecycle boundary. Explain what happens if storage is unavailable or quota is exceeded; the app should have a safe in-memory fallback if persistence is optional.

Instrument an async action

Use $onAction to measure a store action's duration and outcome. The hook can observe when an action starts and use after/onError callbacks for completion. Record action name, duration, and success class, but do not log sensitive arguments or result payloads. Make telemetry failures non-blocking unless the application explicitly requires durable audit records.

Action instrumentation should not duplicate the business action or mutate its state invisibly. If a user-visible transition needs to happen, implement it in the store action itself. Plugins are best for cross-cutting observation and integration, while the store retains domain ownership.

Verify devtools and reset

Open Vue Devtools and inspect state, getters, and the action timeline. Confirm a named action shows a coherent transition. Reset the store between tests and verify the plugin does not restore previous test state from browser storage. Use a fresh Pinia instance for each test and stub storage explicitly.

Mount and unmount a component that registers a subscription. Trigger one action after unmount and confirm no stale listener fires. For a detached app-level subscription, close the app or change identity and verify it is stopped. Run an SSR test with two Pinia instances and ensure their plugin state is isolated.

Manage persistence changes

When the store schema changes, migrate or discard incompatible persisted state intentionally. A storage version can route old values through a migration function. Keep migrations small, test them with old fixtures, and avoid assuming every browser has the newest schema. If persisted preferences are invalid, reset only those preferences rather than clearing unrelated application data.

Plugins operate across store boundaries, so document installation order and ownership. A persistence plugin should know which stores it handles; a telemetry plugin should know which actions are safe to observe. This prevents a generic hook from recording sensitive flows or retaining state beyond the user's session.

Devtools history is most useful when actions have meaningful names and patches are scoped to one logical change. Large opaque snapshots make it harder to identify which operation created an invalid state. Add a state label or action payload only when it helps explain the transition without exposing private fields.

Review action history after a reset to confirm the timeline still explains the transition.

Cross-cutting code can become invisible

Plugins reduce repeated integration code, but they can hide persistence, logging, or mutation behavior from a store's definition. Keep plugin contracts explicit and small. Avoid magic that changes business state based on plugin registration order. Name the fields a plugin handles and test the store both with and without the integration when graceful degradation matters.

Devtools improve development visibility but are not an audit trail. Production observability needs explicit instrumentation, access control, and retention. Do not log full action arguments or state snapshots by default; they may contain personal data or credentials. Record metadata that supports diagnosis while preserving privacy.

Persistence is a product and security choice

Persisting state improves continuity but creates stale-data, privacy, and schema-migration concerns. Browser storage is not trusted for permissions. Use an allowlist, schema version, validation, and reset on identity change. A plugin should handle storage failure and corrupt values predictably. If state is sensitive, keep it server-side or in an approved secure mechanism rather than generic localStorage.

Subscriptions need ownership. Detached subscriptions can outlive views and accumulate across route visits. Store and app-level subscriptions need an explicit teardown path. Test that unmount and logout stop the correct observers without stopping a resource another consumer still needs.

In an interview, explain $subscribe versus $onAction, a safe persistence use case, and why devtools are not production auditing. Discuss unsubscribe behavior, SSR isolation, and sensitive data. This frames plugins as controlled extensions rather than hidden global behavior.

Persisting state introduces a migration boundary. Add a schema version to stored data, validate it when loading, and decide whether to migrate or discard an incompatible version. A corrupted preference should fall back safely rather than preventing the app from starting. Keep migration code deterministic and test it with fixtures from prior versions.

Storage writes can fail because of quota, privacy mode, browser policy, or serialization. Treat persistence as optional unless the product requirement says otherwise. Catch failures, retain usable in-memory state, and report a safe diagnostic. Debounce frequent changes when appropriate, but flush important preferences at a deliberate boundary. Do not use a plugin to persist every store indiscriminately.

Security review should include plugin order and scope. A plugin that sees every mutation may observe sensitive values. Filter stores and fields before persistence or telemetry, and test that excluded values never reach storage or logs. Reset user-scoped stores on logout even if the plugin has a cached serialized copy. Browser-side access to a stored value does not prove that the user is authorized to use it.

In a team setting, document which plugin owns persistence, how its subscription is stopped, and what happens when storage or telemetry is unavailable. Avoid two plugins writing the same field with different formats. A small integration test should install the actual plugin against a fresh Pinia instance, mutate allowed and disallowed fields, then inspect storage and cleanup behavior.

Document the owner and recovery path for every persistence integration.

Verify this policy during upgrades and identity changes.