Svelte 5 shared state: stores vs rune modules in a mixed SvelteKit codebase

Answer

For shared client state that must be reachable from multiple routes, layout files, or SvelteKit load functions, keep it as a Svelte store. Use rune‑based state only when the state is truly private to a module or component.

Why this convention?

Confirmed from the Svelte 5 documentation and community practice:

• Stores (writable, readable, derived) are singleton reactive primitives that can be imported anywhere, survive server‑side rendering, and serialize cleanly in load functions.
• Rune modules ($state, $derived, $effect) are compile‑time declarations scoped to the file where they are defined unless explicitly exported. They are ideal for component‑local or module‑scoped reactivity.

During an incremental migration, treat existing stores as the source of truth for any state that is already imported across files. Only refactor to runes when you can confirm the state is never accessed outside its defining module.

Steps for the migration decision

1. Identify each piece of shared state and list where it is imported:
   • If any import occurs in a different .svelte file, a +layout.svelte, a +page.svelte, or a SvelteKit load function → keep as a store.
   • If all imports are within the same .svelte.js module (or its sub‑modules) → consider moving to runes.
2. For state that stays a store, leave the existing $store usage unchanged.
3. For state you decide to move to runes:
   • Create a .svelte.js file (e.g., src/lib/uiState.js) and declare the state with $state (or $derived for derived values).
   • Export the rune(s): export const count = $state(0);
   • In any component that still uses the $store syntax, keep a thin store wrapper that mirrors the rune:

   import { writable } from 'svelte/store';
   export const count = $state(0);
   export const countStore = writable(count);
   $: countStore.set(count); // keep store in sync with rune
   

   This wrapper ensures legacy $countStore subscriptions work without duplicating the source of truth.

4. Verify the wrapper:
   • Log the store reference in two different components to confirm it is the same object.
   • Update the rune (count += 1) and check that all $countStore subscribers receive the new value.

Interop pattern: sharing rune‑based state with store consumers

The recommended pattern is the thin wrapper shown above. It preserves a single source of truth (the rune) while providing a store‑compatible API for existing code. No duplication of state occurs because the store merely forwards the rune’s value via an $effect (the $: countStore.set(count) line).

Mixing stores and runes in a component tree

There is no inherent performance penalty; Svelte batches updates within the same microtask. The only risk is accidental double‑subscription if both a store and a rune listen to the same source. Ensure that:

• You never subscribe to a store and also derive a rune from that same store without cleaning up.
• In devtools, observe that each update triggers a single UI flush.

If you notice extra renders or unexpected ordering, check for duplicate subscriptions.

One missing diagnostic detail

To finalize the recommendation, please confirm: Is the shared state accessed inside any SvelteKit load function? If yes, the state must remain a store to survive serialization and server‑side execution.