Svelte Stores: State for Async Streams & Legacy Apps
Svelte Stores are objects for sharing reactive state. While Svelte 5's runes ($state) are now preferred for simple state sharing, stores remain ideal for complex async streams or when you need manual control over updates.
Why it exists
To provide a way to manage state that lives outside of any single component, allowing different parts of an application to react to the same data changes. Before Svelte 5, this was the primary method for any shared state that wasn't passed down through props.
The mental model
A store is a reactive value container, like a global variable that components can subscribe to. When the store's value changes, all subscribed components automatically update. You interact with it in components using a special $ prefix, which turns the store reference into its underlying value.
How it works
The svelte/store module provides functions like writable to create stores. A writable store is an object with set and update methods for changing its value from anywhere. In a component, you import the store and then read its value with storeName. You can also write back to it with storeName = newValue, which is syntactic sugar for the store's set method.
When to use it
In Svelte 5 and later, stores are best for specific, complex situations. Use them when you need to manage intricate asynchronous data flows, like from a WebSocket or a library like RxJS. They are also useful when you want explicit, manual control over state transitions, which the set and update methods provide.
When not to use it
For simple shared state between components in a Svelte 5+ project. The modern, idiomatic solution is to use runes. For example, exporting a $state variable from a .svelte.js file is simpler and more direct for sharing user data or UI state. Using a store for this is now considered overkill and less performant.
One canonical example
To share a user's login status, you might create a writable store: import { writable } from 'svelte/store'; export const user = writable(null);. A login component could call user.set({ name: 'Alice' }); upon success. A navbar component could then display the user's name by reading $user.name. If another component calls user.set(null) on logout, the navbar will automatically update.
Interview question
In a Svelte 5+ application, when is a Svelte Store the most appropriate choice?
- a.To handle complex asynchronous data flows or require explicit state transition control.Correct
- b.For managing simple, shared UI state between components.
- c.When defining reactive state that is local to an individual component.
- d.To store static application configuration that does not change at runtime.
Why? this is the answer
Svelte Stores are best for complex asynchronous data flows (e.g., WebSockets) or when explicit control over state transitions is needed. For simple shared state, Svelte 5's $state runes are now the preferred and more performant solution.
Just read this? Test yourself on what you have been reading.
Read the original → svelte.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on svelte — each one lists the topics its interview covers.
See open roles