svelte: Store is not being updated synchronously / store value is incorrect

First of all, store.set(value) is synchronous.

if you call store.set(5), you should be able to read the value out of the store immediately, get(store) === 5.

Secondly, the magic of $store is:

let $store;
store.subscribe(store, (value) => $store = value);

$store is another variable that stays in-sync with the store value by subscribing to it

in most cases, the subscribe callback function is called synchronously, so you can do:

store.set(5);
console.log($store); // 5

so what happened in the above code is that:

1. store.set(5) will synchronously loop through the subscribers function and call them
2. (value) => $store = value) is evaluated, therefore the value of $store updated to 5
3. after all the subscribers are looped through, the store.set(...) method returns, and …
4. console.log($store) prints out 5

allow me to break down what happen instead, if you write $store = 5, as some of you are confused and wonder what’s the difference between store.set(...) and $store = ...

when you write $store = 5 in a .svelte component, it is compiled into:

store.set($store = 5);

1. $store = 5 updates the variable $store to 5
2. the expression $store = 5 returns 5, therefore store.set(5)
3. store.set(5) will synchronously loop through the subscribers function and call them
4. (value) => $store = value) is evaluated, therefore the value of $store updated to 5, though at this point, it is already 5
5. after all the subscribers are looped through, the store.set(...) method returns

strictly speaking, in this case, the value of $store gets update, even before value of the store gets update, but it all happen within the same statement, it is unlikely to have a race condition.

---

Now, if we are all aligned with the fundamentals of store, here is what introduced this bug:

https://github.com/sveltejs/svelte/pull/3219

which introduced an optimisation to update store value via breadth-first approach, vs depth-first approach, as explained in https://github.com/sveltejs/svelte/pull/3219#issuecomment-515444121

how would that impact in our case? let’s take a look at the following example:

let store = writable(5);
store.subscribe(() => {
	store.set(10)
	console.log($store);
});
store.set(30);

repl

we subscribe the store and call store.set() in the subscriber function to update the store value to 10, (it wont lead to infinite loop, because internally, writable will not notify the subscribers if the value is set to the same value), so you set it to 30, it will set it to 10 and then it will try to set it to 10 again, which will be a noop.

guess what is the value of $store inside store.subscribe(...) ? you’ll see the function being called a few times, but you’ll find 30 is printed among them!

so, if the store is updated in depth-first approach, whenever you call store.set(...) it will call the subscriber callback function immediately, and update the value of the $store:

1. store.set(30)
   1. calls (value) => $store = value to update the $store to 30
   2. calls () => { ... }
   3. which calls store.set(10)
      1. calls (value) => $store = value to update the $store to 10
      2. calls () => { ... }
      3. which calls store.set(10)
         1. at this point of time, the value of the store is already 10, so it is a noop.
      4. console.log($store) prints out 10
   4. console.log($store) prints out 10

Run the above code in v3.6.8 which was before the optimisation got introduced, and you’ll see the above REPL

However, now it is run in breadth-first approach:

1. store.set(30)
   1. calls (value) => $store = value to update the $store to 30
   2. calls () => { ... }
   3. which calls store.set(10)
      1. schedules (value) => $store = value
      2. schedules () => { ... }
   4. console.log($store) prints out 30
   5. calls the scheduled (value) => $store = value to update the $store to 10
   6. calls the scheduled () => {...}
      1. which calls store.set(10)
         1. at this point of time, the value of the store is already 10, so it is a noop.
      2. console.log($store) prints out 10

now see that the inner store.set(10) schedules the update of the variable $store, therefore you see $store = 30?

that’s exactly what happened in this issue:

random.subscribe(v => reset())

const updateRandom = () => random.set(Date.now())

function reset () {
	count.set(0)
	console.log('count should be zero ', $count)
}

calling random.set(), which in the subscribe function calls count.set(0) -> causes the (value) => $count = value get scheduled, therefore printing the value out immediately still show the old $count value.

but if you do:

const updateRandom = () => {
  random.set(Date.now())
  console.log('count is zero', $count);
};

you’ll see 0, since random.set() started the store update chain, when it finishes, the value of $random and $count should already been updated.

so, what then?

---

Workaround / Solution

Use reactive declaration:

$: $random, reset();

@jhwheeler as pushkine said, when you use assignment Svelte assumes that assignment is what you want and sets the store value immediately, regardless of what then happens in set(). Calling set() directly avoids this behavior (might be desirable for custom stores), though frankly I think you’d usually be better off naming the method something else and avoiding the confusion of it also being called after assignment.

I was confused enough by this to ask about it on Stackoverflow. I agree with antony; I would have expected set() and assignment to have the same behavior by default.

AFAIK in the docs it says store.set(value) is the proper way to set a store’s value, so I would say it’s a bug that it doesn’t work as described.

And if $count = 0 works, but count.set(0) doesn’t, then why do we even have the function syntax? 😕 We should just use the assignment syntax everywhere instead.

I am running into this and having to unwind a ton of code to try and exactly identify where the problem(s) originates. I typically used $store over store.set but had to use store.set when using in my typescript portions. Was the optimization gain from https://github.com/sveltejs/svelte/pull/3219 worth the side-effect?

in your examples, the second store is not a store you’re only using the event dispatching feature of the store

In fact, in my real-world example the second store is a store.

that only hides bad uses of stores such as this one

I need the filter to be a store because it is part of the app state. So, if filter is a store anyway and I need to perform an operation when its value changes, how is it a “bad use” to perform this operation in the subscribe function? 🤔

Anyway, the point of this thread is to report an obvious bug and not to discuss code quality.

svelte store sets are always synchronous

in your examples, the second store is not a store you’re only using the event dispatching feature of the store

the issue is that stores updated by other stores are assumed to be derived stores, so svelte treats them differently

$count = 0 does work because it’s known “for sure” that $count will be set to 0, so it sets the value locally at the same time as it calls count.set

set_store_value(count, $count = 0);

that however is willy-nilly compiler optimization that should be removed, as that causes stores such as tweened and spring to be temporally out of sync with the local component value and it only works locally as $count will still be out of sync in other components

the value should be set synchronously anyway so setting it locally at set_store_value before it gets set in component_subscribe is just unnecessary extra work that only hides bad uses of stores such as this one

It does work, but it is async.

I think $count = 0; has something like a “auto await tick”, because if you change the reset function like this

import { tick } from 'svelte';
async function reset () {
	count.set(0)
	await tick
	console.log('count should be zero ', $count)
}

it works.