-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Derived stores are re-evaluated on invalid upstream state #10557
fix: Derived stores are re-evaluated on invalid upstream state #10557
Conversation
|
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? |
|
||
/** @type {Set<import('./private').SubscribeInvalidateTuple<T>>} */ | ||
const subscribers = new Set(); | ||
|
||
function invalidate() { | ||
if (invalidated) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can use early return pattern
if (invalidated) | |
if (invalidated || !stop) return; | |
invalidated = true; | |
// immediately signal each subscriber as invalid | |
for (const subscriber of subscribers) { | |
subscriber[1](); | |
} |
Closing per #10575 (comment) |
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:
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:
This creates a dependency graph something like:
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:Following the diagram, it's clear at point (5) that store
c
is evaluating prematurely. At point (5) storec
believes both its dependencies to be valid, but in fact onlya
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 toa
.