⚠️ No Changeset found

Latest commit: 8d63f70

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.

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

Playground

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

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

I think we've discovered something majorly broken here, and maybe made it worse on main?

• latest released version: clicking "other" increments only the count that is initialized in the template and the one with top-level await (but no template await). Once I click "increment" nothing is reactive anymore
• main: almost nothing works anymore (same on this PR)

My original idea for making this playground was to show that removing wait from these deriveds can result in the wrong values being used: If you are newly creating this function as part of an async batch, but then don't reapply it, the values afterwards will not read the value that this batch sees, instead they read the latest version. If there are multiple batches going, this can result in tearing/wrong values. But as you can see I didn't even get that far.

I notice that these...

{(await x).value}
{(await y).value}
{y.value}
{(await fn()).value}

...aren't being transformed to use $.save(...):

$.template_effect(
	// ...
	[
		async () => (await x).value,
		async () => (await y).value,
		async () => (await fn()).value
	],
	// ...
);

So when .value is read, we're no longer in an effect context. By extension, combined is never connected to the effect tree, so changes to its dependencies don't cause effects to reschedule.

Other than that, I think the behaviour in this PR is an improvement on main, at least insofar as it's consistent (the behaviour doesn't change after you first increment).

(This, incidentally, is also the source of the await_reactivity_loss warning)

Think I just fixed it, but about to jump on a call so will add a test later

Still broken, but differently — other updates everything, until you click increment which severs the link

Haven't fully figured this out but I think it's at least partly because count belongs to the effect, and thus isn't treated as a dependency of the effect. So it's not something that we should expect to work.

Since it's tangential to the main purpose of this PR, and since we're in a better state here than we were on main even if it's not fully resolved, my inclination would be to merge this and file it under 'weird edge cases to look into later'