fix: Derived stores are re-evaluated on invalid upstream state

[WHenderson]

Svelte 5 rewrite

This PR specifically targets svelte 5 though the issue this PR addresses is relevant to svelte 5 and svelte 4.
I would be happy to make a svelte 4 PR once this one is resolved.

Before submitting the PR, please make sure you do the following

This PR addresses #10376.

Currently, a change to a store's value only causes stores which are immediately dependent on it to be invalidated. Svelte does not propagate invalidation downstream to subsequent derived stores, and this can cause issues when two criteria are met:

• the store dependency graph forks and merges again at least once; and
• the two or more paths between the fork and merge points are of unequal length.

Svelte's current implementation correctly handles dependency diamonds, but such cases do not meet the second criterion; unequal path length.

Example

Consider the following example:

const a = writable(1);
const b = derived(a, a => a*2);
const c = derived([a,b], ([a,b]) => a+b);
c.subscribe(c => console.log(c));
...
<input type=number bind:value={$a} />

This creates a dependency graph something like:

Loading

stateDiagram-v2
	direction RL
  
	input
	a
	b
	c
	log

	log --> c
	c --> b
	b --> a
	c --> a
	a --> input

Svelte's Current Implementation

With sveltes current implementation, the derived store c will prematurely evaluate every time store a changes.
In the example above, if we change the input to 2, the current implementation will go through the following sequence:

Loading

sequenceDiagram
	autonumber
	
	participant input
	participant a
	participant b
	participant c
	participant log

	note right of a: a == 1
	note right of b: b == a * 2 == 1 * 2 == 2
	note right of c: c == a + b == 1 + 2 == 3

	input ->> a: 2
	note right of a: a == 2
	a -->> c: invalidate
	activate c
	a -->> b: invalidate
	activate b
	a ->> c: 2
	deactivate c
	rect rgb(255, 128, 128)
	note right of c: c == a + b == 2 + 2 == 4
	c ->> log: 4
	end
	a ->> b: 2
	deactivate b
	note right of b: b == a * 2 == 2 * 2 == 4
	b -->> c: invalidate
	activate c
	b ->> c: 4
	deactivate c
	note right of c: c == a + b == 2 + 4 == 6
	c ->> log: 6

Following the diagram, it's clear at point (5) that store c is evaluating prematurely. At point (5) store c believes both its dependencies to be valid, but in fact only a has been resolved at this point.

The correct behaviour would be for invalidations to be "deep" and for resolution to only occur once all dependencies are fully resolved. Thus in the given example, c should only emit once for each change to a.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4e666de

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Rich-Harris]

Thank you for the PR and for the detailed explanation! I think we can make the fix a tiny bit simpler by giving the derived store access to its own subscribers, and so I've opened an alternative PR at #10575 which proceeds from this branch. What do you think?

[GaroGabriel]

you can use early return pattern

Suggested change

	if (invalidated)
	if (invalidated || !stop) return;
	invalidated = true;
	// immediately signal each subscriber as invalid
	for (const subscriber of subscribers) {
	subscriber[1]();
	}

[Rich-Harris]

Closing per #10575 (comment)