fix: guard contents updated before the guard itself

[hmnd]

Fixes #16850, #16775, possibly #16795

#16631 introduced a bug that results in the effects within guards being evaluated before the guards themselves. I believe iterating the effects in reverse fixes the issue without any further regressions. An alternative approach could be to actually sort effects by depth before updating, but I suspect that would have a greater performance penalty.

Although all tests pass, sorry if I'm missing something obvious! I've never touched the Svelte internals until now :).

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 with feat:, fix:, chore:, or docs:.
• 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 within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 140ee11

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

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

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]

Preview: https://svelte-dev-git-preview-svelte-16930-svelte.vercel.app/

[github-actions]

Playground

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

[PatrickG]

It seems like this fixes the issue described here - but only for its first occurrence.
Clicking the button once does not log "one" anymore. Clicking it three times still logs "one".
repl with this PR

[dummdidumm]

Can you explain what the tests are supposed to test? Most (haven't checked all but the first 4 do) also pass on main, and some of them have if conditions that are never true.

I think we should reduce this only to the ones that pass with this PR but fail on main.

[hmnd]

Can you explain what the tests are supposed to test? Most (haven't checked all but the first 4 do) also pass on main, and some of them have if conditions that are never true.

I think we should reduce this only to the ones that pass with this PR but fail on main.

The tests I committed were falling (multi-nested was failing against that pr), but I didn't look too closely at the tests commit I cherry picked from the previous PR.

I'll clean those up and take a stab at @PatrickG's issue today.

[hmnd]

It seems like this fixes the issue described here - but only for its first occurrence. Clicking the button once does not log "one" anymore. Clicking it three times still logs "one". repl with this PR

It looks like sorting eager effects by depth does fix this issue, so that may be necessary after all. Perhaps more efficient to sort higher up the chain in mark_reactions... Best to sort when updating, because mark_reactions could be called multiple times for the same batch of effects.

[hmnd]

@dummdidumm all cleaned up. I've also switched to sorting the effects by depth to account for @PatrickG's repro in #16775 (see the guard-else-effect sample)

[hmnd]

It seems it still doesn't fix the main issue within #16775 though, hmm...

[PatrickG]

It doesn't seem like sorting the effects by depth fixes the issue. Clicking the button three times still logs "one" - same as with the simple reverse.

[hmnd]

@PatrickG yeah, I noticed... I'll look into it further tomorrow!

[hmnd]

@dummdidumm to be honest, as much as I'd love to fix this myself, I'm kind of at a loss on how to retain the changes in #16631 while fixing all the issues it has introduced. I'm sadly not knowledgeable enough on Svelte's internals to figure this out. I think trying to sort the effects here is just fixing a symptom downstream of the issue rather than the issue itself, as visible by the playgrounds in #16775.

But what I can tell is that #16631 introduced some really nasty side effects. It may be a good idea to either prioritize fixing it or revert it until a fix can be found. The couple of tests in this pr and the playground in #16775 are good ways to reproduce the bugs here.

If there's any other way I could assist figuring this out, do let me know!

[hmnd]

Never mind! I think I've got it. Eager effects were still executing after being destroyed, in addition to executing out of order.

[hmnd]

@PatrickG I believe I've now got the fix to your issue nailed down too. I've also ensured the guard-else-effect test based on your repl tests clicking multiple times so we don't get a false positive.

[PatrickG]

@PatrickG I believe I've now got the fix to your issue nailed down too. I've also ensured the guard-else-effect test based on your repl tests clicking multiple times so we don't get a false positive.

Very nice 👍

[gyzerok]

Great job with the fix! We are struggling from a similar issue, but unfortunately not able to reporduce it so far. Hopefully that is it :)

In our code this sometimes throws Could not @render snippet due to expression being null or undefined.

{#if someSnippet}
  <div in:scale>
    {@render someSnippet()}
  </div>
{/if}