Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix: abort and reschedule effect processing after state change in user effect#16280

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
Rich-Harris merged 4 commits intomainfromgh-16072
Jul 7, 2025

Conversation

Rich-Harris
Copy link
Member

Fixes#16072. It's a real edge case, hence the convoluted nature of the test, but it'spossible for a state change in one effect to cause a subsequent already-scheduled effect to run even though the second effect would be destroyed if the effect tree was being processed from the root.

The solution, I think, is to abort the processing of effects if a state change occurs. We can schedule the remaining effects and start again from the top; this will ensure that any dirty branches (i.e. a now-falsyif containing an effect with a now-broken reference) are updated before their children. Within each flush of the effect tree, predictable order is preserved.

We need to distinguish between user effects and non-user effects, since element bindings can result in state changes, and these shouldnot cause flushing to be aborted (they are guaranteed to run before the effects that depend on the changed state, so this is not a problem).

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

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC:https://github.com/sveltejs/rfcs
  • Prefix your PR title withfeat:,fix:,chore:, ordocs:.
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.
  • If this PR changes code withinpackages/svelte/src, add a changeset (npx changeset).

Tests and linting

  • Run the tests withpnpm test and lint the project withpnpm lint

SymphonySimper reacted with rocket emojiKonstantinos-Ps reacted with eyes emoji
@changeset-botchangeset-bot
Copy link

changeset-botbot commentedJul 2, 2025
edited
Loading

🦋 Changeset detected

Latest commit:8d82339

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
NameType
sveltePatch

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

@svelte-docs-bot
Copy link

@github-actionsGitHub Actions
Copy link
Contributor

Playground

pnpm add https://pkg.pr.new/svelte@16280

@dummdidumm
Copy link
Member

dummdidumm commentedJul 2, 2025
edited
Loading

This is a good solution IMO - it doesn't yet work for$effect.pre though, since that's executed in another part. If I change the reproducible to use$effect.preit still fails

Adding similar logic toprocess_effects and returning an empty array seems to fix it.

@Rich-Harris
Copy link
MemberAuthor

Good catch. Rather than making changes toprocess_effects, which will create more merge headaches with theasync branch, I think we should park this until that branch is merged. Adding a failing test in the meantime

@Rich-Harris
Copy link
MemberAuthor

I've skipped the$effect.pre for now in the interests of merging — we can revisit it onceasync is in

@Rich-HarrisRich-Harris merged commitcf2ff5e intomainJul 7, 2025
14 checks passed
@Rich-HarrisRich-Harris deleted the gh-16072 branchJuly 7, 2025 15:46
@github-actionsgithub-actionsbot mentioned this pull requestJul 7, 2025
@abtinturing
Copy link

abtinturing commentedJul 7, 2025
edited
Loading

I was having a problem similar to#16072 and after pulling the latest update, it's still there. It happens only if there is an$inspect in the components inside anif directive.

I wasn't able to reproduce exactly that scenario, but I got another issue when trying to recreate it, which also is running code before theif directive executes. Here's asimple REPL, where when you click the button, it assigns undefined to activeTab, which should make the child component disappear, but some code is still running within theif directive, attempting to read from activeTab, and it throws an error (If you remove the$inspect inside the child, the error goes away):
image


As for my original problem, all I can provide are these screenshots since I couldn't reproduce, but this is just for reference, the REPL above is enough to trigger the issue:

Here's the error:
image

And here's where that error is thrown, which as you can see, that code shouldn't even be running given the condition of theif statement.:
image

@PatrickG
Copy link
Member

@abtinturing please create a new issue.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@dummdidummdummdidummdummdidumm approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Re-rendering occurs before the execution of the #if directive.
4 participants
@Rich-Harris@dummdidumm@abtinturing@PatrickG

[8]ページ先頭

©2009-2025 Movatter.jp