$state the new store ?

[MentalGear]

I was under the impression that $state are meant to replace stores. Yet, if they can't be used in normal js/ts files (e.g. to run unit tests), their usability seems quite limited. I think a comparison table would be helpful when to use a store vs state.
Also, will stores also gain deep fine-grained reactivity in svelte 5 ?

I guess $state is a compiler level feature, but I'm wondering if it would be truly impossible to make it importable so it can be used in any js files, rendering stores obsolete while allowing for straightforward use with TDD.

[thoughtspile]

+1 this question. I'm considering open-sourcing our store helper library, but if stores won't be a large part of svelte 5 I'd rather wait for runes to stabilize before releasing anything.

[MentalGear]

I have done some playing around with state in a try out app, and so far it seems like $state can be used like stores, but with the additional benefits of not needing special syntax/methods (can be used just like any object) and fine-grained nested reactivity - I'm even starting to wonder if a whole app can be driven by a single $state.

[Prinzhorn]

I don't see stores going anywhere as $state is incompatible and serves a different purpose:

1. AFAIK it's impossible to implement something like StartStopNotifier with $state because of how signals work. The "root" state has no idea if and how many listeners nested state has.
2. With stores you explicitly want the all-or-nothing updates to, well, store the value somewhere (at least for writable). With fine grained reactivity this won't work. I use stores because I explicitly want and need to be notified when a value changes, no matter how deeply nested it is. I don't see this being possible for $state either for the same reason as 1.

For readable stores, however, I'd love to have fine grained reactivity. I can't use $state because of missing StartStopNotifier logic.

However, I haven't really played with Svelte 5, so maybe all of this is actually possible with $state?

[brunnerh]

StartStopNotifier can be modelled using $effect.active() on value access.
(Edit: This rune no longer exists, there now is $effect.tracking() and createSubscriber.)

Example that was shared on Discord: REPL (Source)

Reacting to any deeply nested change should be possible by recursively evaluating the given object, though maybe a utility function for this would be helpful.

[Prinzhorn]

Thanks for posting the example. My use-case is different (basically let timer = $derived(create_timer(some_other_state))) but it seems to work too. I won't claim I understand how it works. But I haven't actually done any Svelte 5 outside of REPL and looking into issues.

[Prinzhorn]

I will say using tick() does not sit well with me. Couldn't there be some funny edge case with nested stuff that would result in a race condition?

[brunnerh]

The code looks fine to me. As long as the logic that checks the subscriber count and acts on it is not separated by async operations, the code cannot be interrupted by any other code.

[kinthaiofficial]

$state in Svelte 5 runes is indeed the conceptual replacement for the older writable store pattern, but with important differences:

$state vs writable store:

• $state is compile-time reactive — the Svelte compiler tracks exactly where the value is read and updates only those locations. No runtime subscription overhead.
• writable stores are runtime reactive — you subscribe, Svelte tracks subscriptions, updates propagate through the subscription graph.
• $state is component-scoped by default. A writable store is naturally shareable across components by import.

For shared state across components:

<!-- state.svelte.js -->
export const count = $state(0);  // exportable, shared across importers

This is the runes-era equivalent of a store. Unlike a writable store, it doesn't need .subscribe(), .update(), or the $ prefix for auto-subscription in templates — you use it directly.

For local component state:

<script>
  let count = $state(0);  // local to this component
</script>

The conceptual shift:
Stores were Svelte's solution to the problem "how do I share reactive state outside of components". Runes bake reactivity into the language itself, so sharing reactive state becomes trivial — just export a $state value from a module.

The migration path: if you have writable stores used only within one component, convert to $state. If they're shared, convert to exported $state in a .svelte.js module.

What's the specific use case you're trying to figure out the right pattern for?

[seantiz]

I feel the tail of this thread shouldn't end on misinformation, which could cost any reader time if they tried to directly export state. So I'm just going to leave this link to the docs:

https://svelte.dev/docs/svelte/$state#Passing-state-across-modules