Observer still called when unsubscribed during store update

[pushkine]

https://svelte.dev/repl/703dd3e1045543388fd5583c489bac55?version=3.22.2

const store = writable(0);
let is2cancelled = false;
const cancel_sub1 = store.subscribe((v) => {
	if(v === 1){
		cancel_sub2()
		is2cancelled = true
	}
});
const cancel_sub2 = store.subscribe((v) => {
	if(v === 1 && is2cancelled){
		console.log('I have been cancelled already');
	}
});
store.set(1); // logs 'I have been cancelled already'
cancel_sub1();

will fix with #4742 unless someone thinks this behavior is expected ?

[dimfeld]

One concern with changing this is that it potentially relies on the observers being called in the same order in which they were subscribed. For example, if in the future stores are changed so that the callbacks are called in reverse order of subscription, the behavior of the example above would change so that both callbacks are called once again.

With that in mind, I think I would feel most comfortable with this change if Svelte made one of these behaviors official:

1. Store subscriptions will always be called in the same order that they subscribed.

or

2. There is explicitly no guarantee about the order in which subscribers are called. Kind of the same thing that Go says about iterating over maps.

What do you think?

[pushkine]

Observables are just arrays of callbacks so as per ECMA the order is guaranteed, I don't see how that could change in the future

[dimfeld]

The most obvious possibility in my mind is that at some point in the future there is a need for better performance of unsubscribing, and so the array of subscribers is replaced with some other data structure. It would probably be a Map though, and so iteration would still be in insertion order. I suppose some other change could necessitate iterating in reverse order, but I cant think of any real reason to do that.

But mostly I'm just thinking about the formal promises made by the Svelte API vs. the logical, but undocumented behavior that it exhibits, such as iterating over subscribers in the order they were added. If the answer is that I'm just worrying too much, that's fine and I'm happy to drop the issue :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.