await blocks unnecessarily unmount and remount their children when the promise changes

[lovasoa]

Describe the bug

When the promise of an {#await ... } block changes from a resolved Promise to another resolved Promise, svelte unnecessarily unmounts and then remounts all the contents of the "then" fragment of the await block.

Reproduction

https://svelte.dev/repl/b70b678cc4304ccdac16419e6a979168?version=3.58.0

<script>
  	import ShowValue from "./ShowValue.svelte"
	
	const promise_a = Promise.resolve('a')
	const promise_b = Promise.resolve('b')

	let current_promise = promise_a;
</script>

{#await current_promise then value}
	<ShowValue {value} />
{/await}

<button on:click={()=>{current_promise = promise_a}}>Show Promise A</button>
<button on:click={()=>{current_promise = promise_b}}>Show Promise B</button>

Here, I wouldn't expect ShowValue to be unmounted and remounted when the buttons are clicked.
In more complex cases, when ShowValue is expensive to mount (when it has to do many DOM operations, for instance), this becomes a performance problem.

Logs

No response

System Info

Tested in svelte 3.58.0

Severity

annoyance

[lovasoa]

The bug only appears with the then and error blocks, but not in the pending block. Replacing a pending promise with another pending promise does not unmount and remount the pending block.

[lovasoa]

I wrote a small component to use instead of the native {#await} that works around this problem

<script>
	const PENDING = {};
	let data = PENDING;
	let error = PENDING;
	
	export let promise;
	
	async function onChange() {
		[data, error] = await Promise.race([promise, PENDING]).then(
			d => [d, PENDING],
			e => [PENDING, e],
		);
		if (data === PENDING && error === PENDING) promise.then(onChange, onChange)
	}

	$: onChange(promise)
</script>

{#if data !== PENDING}
	<slot {data} />
{:else if error !== PENDING}
	<slot name="error" {error} />
{:else}
	<slot name="pending"/>
{/if}

It can be used like so

<Await {promise} let:data>
	Resolved with {data}
	<div slot="pending">Pending...</div>
	<div slot="error" let:error>Error: {error}</div>
</Await>

[Rich-Harris]

The current behaviour isn't buggy per se, but it probably would be better to delay the update by a single microtask when changing from one promise to another, in case the latter resolves in that window. Adding the 5.0 milestone so we can review (it is technically a breaking change so would need to happen in a major)

[trueadm]

After looking into this, I'm not sure delaying by a microtask gives us anything. This is a bit like a key block in that the promise is different, so we unmount and remount. I think the existing behaviour actually makes sense here.

[lovasoa]

Maybe it's just me (and the 5 people that upvoted this issue), but I found the current behavior impractical. The way it manifests in applications is most often with intempestive loading spinners and unneeded backend requests being made. Fixing this would, I think, just make applications snappier in most cases, and I don't see any obvious downside to it.

[trueadm]

Let me take another look at what we can do then.

[rmunn]

Here's a Svelte 5 copy of the original REPL, showing that the bug has indeed been fixed in Svelte 5:

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAA51S0UrDMBT9lWt8aAtjfa9ZYb4LguKLkZF2dy6YJiFJNyX0323arhMnIj609N6ec3LuPQlkJyQ6UjwHoniDpCBrY8iC-A8TC3dA6bGvnW5tHTvU1VYYXzIFIBqjrYeHvT4-cdki7KxugJFlPreWowIjTDEfn1or58H0QOFww2EF9-P30qLT8oBpwpPsEln9hKwGZI-V6KFurUXlNxOjx8-n3DBF89k4U-GaH7m4pPg9KjhE311UpefJwtiFvOeHfGBHiKJV671WoFVRS1G_rUKarcrwi5euK6PsaRhY03zUKP-hVn1Xu53V-tAavRU7gVtSeNubX8wZz3P9NWnA9yHquOdhE3E9MLymSxC0utOt8t3pEnwNfvqXxmm4ROvT5Lxa4aBCoV7BYhNRuIWrJMu-Rfa4x1Nco4PIo8ZiOUVD81hcTv3SfQI-_jjj5QIAAA==