Svelte Derived Stores: Reactive Values from Other Stores
A Svelte derived store is like a spreadsheet formula for your state. It listens to other stores and automatically computes a new value whenever they change. The footgun is trying to write to it—it's read-only; you must update its sources instead.
Why it exists
To solve the problem of keeping related pieces of state synchronized. Manually updating a computed value (like a user's full name) whenever its parts (first name, last name) change is tedious and error-prone. Derived stores automate this reactivity, ensuring consistency.
The mental model
Think of a derived store as a spreadsheet formula. It watches one or more "cells" (source stores) and automatically recalculates its own value whenever any of its dependencies change. You can read its value, but you can't set it directly—you change the input cells instead.
How it works
You create a derived store by calling the derived() function from svelte/store. You provide it with one or more source stores and a callback function. Svelte subscribes to the source stores. When any of them are updated, Svelte invokes your callback with the new values of the source stores. The return value of your callback becomes the new value of the derived store. The resulting store is always readable, not writable.
When to use it
Use a derived store whenever you have a piece of state that is purely a function of other state. This is common for things like combining a first and last name into a full name, calculating the number of items in a shopping cart, or filtering a list of todos to show only the completed ones.
When not to use it
Do not use a derived store for state that is a primary source of truth or needs to be set directly by user actions. For example, the value of a text input should be in a writable store. A derived store is for values that are a consequence of other state, not the source itself.
One canonical example
To create a fullName store that reacts to changes in firstName and lastName stores, you would write: import { writable, derived } from 'svelte/store'; const firstName = writable('Ada'); const lastName = writable('Lovelace'); const fullName = derived([firstName, lastName], ([firstName, lastName]) => {firstName} {lastName}); Now, if you call firstName.set('Grace'), the fullName store will automatically update to 'Grace Lovelace'.
Interview question
For which of the following use cases would a Svelte derived store be the most appropriate choice?
- a.Storing the user's selected theme preference (e.g., 'dark' or 'light').
- b.Holding the value of a form input field that the user is actively typing into.
- c.Displaying a "Welcome, [Full Name]!" message based on separate first and last name stores.Correct
- d.Managing the current page number in a pagination component.
Why? this is the answer
A derived store is ideal for values that are purely computed from other stores, like combining first and last names into a full name. Options A, B, and D describe primary sources of truth or direct user input, which require writable stores.
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