fix: ensure async batches get noticed of new effects #17101
+190
−6
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If you have a value X that causes a pending batch, and while that batch is pending cause creation of another batch which creates a new branch and therefore new effects which also read that value X, those template effects are not correctly rescheduled once the pending batch resolves because the pending batch does not know about them. As a result, the shown values of X get out of sync (once shows the old, once the new value). This partially fixes that by telling the pending batch about the newly created effects. Partially fixes #17099, but not completely because effects that are only indirectly relying on the source that change update, but those that directly rely on the source do not. In this example that means if you do `{x}` in the template it does not work, because it directly invokes the source x, but if I do e.g. `{JSON.stringify(x)}` it does work because the intermediate derived is marked as outdated and therefore reruns, reinvoking the source getter in the process. I assume it's because `MAYBE_DIRTY` for the effect isn't enough, since the version check logic determines that the effect's dependencies aren't newer. I believe we can only fix that by changing the strategy and going back to rerunning `mark_reactions` on changed sources in a batch similar to how it was before #16487 but without running into the infinite loop problem, possibly by keeping track of which of these reactions are async effects that have already run.
🦋 Changeset detectedLatest commit: cd9f093 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If you have a value X that causes a pending batch, and while that batch is pending cause creation of another batch which creates a new branch and therefore new effects which also read that value X, those template effects are not correctly rescheduled once the pending batch resolves because the pending batch does not know about them. As a result, the shown values of X get out of sync (once shows the old, once the new value).
This partially fixes that by telling the pending batch about the newly created effects.
Partially fixes #17099, but not completely because effects that are only indirectly relying on the source that change update, but those that directly rely on the source do not. In this example that means if you do
{x}in the template it does not work, because it directly invokes the source x, but if I do e.g.{JSON.stringify(x)}it does work because the intermediate derived is marked as outdated and therefore reruns, reinvoking the source getter in the process.I assume it's because
MAYBE_DIRTYfor the effect isn't enough, since the version check logic determines that the effect's dependencies aren't newer. I believe we can only fix that by changing the strategy and going back to rerunningmark_reactionson changed sources in a batch similar to how it was before #16487 but without running into the infinite loop problem, possibly by keeping track of which of these reactions are async effects that have already run.Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.packages/svelte/src, add a changeset (npx changeset).Tests and linting
pnpm testand lint the project withpnpm lint