Svelte 5: Props consumed from onDestroy are revalidated if not consumed in the template

[wildyaboku]

Describe the bug

This is hard for me to explain, but I will try my best. I first identified this issue from my SvelteKit app after migrating, but was able to replicate the bad behavior in standalone Svelte and even on the REPL.

When passing a prop to a child component, the value of the prop is seemingly recomputed or revalidated during dismount if both of the following are true:

• The value of the prop is consumed by the component in some way during onDestroy
• The value of the prop is NOT consumed by the component's template

To demonstrate this, I wrapped the value of the prop (from the parent component) in a middleman logger function, e.g.

<DataConsumer data={log(data)} />

Ideally, this log function would only run initially when the component mounts (and in other situations, when the data changes).

However, when the child component is dismounted, that log middleman function is invoked by Svelte an extra time when the above conditions are true. Otherwise, the log function is invoked as expected.

To clarify, a middleman function is not required, and is merely being used to show that the prop is being revalidated. Any complex logic in the prop can cause render-breaking errors.

In an environment like SvelteKit, the data is often undefined at this time (such as when it is derived from page data and we're navigating away), which often led to "Cannot read properties of undefined" errors. For example:

<LinkedData data={data.reviews.richData} />

Currently in SvelteKit, if the LinkedData component matches all of the above conditions, then this code would cause a render-breaking error when navigating away, as data becomes undefined before it attempts to revalidate the prop expression data.reviews.richData.

Reproduction

https://svelte.dev/playground/085d926d44e845e6b3d06cc59a6f9fc8?version=5.1.4

The "toggle consumer" button will mount/dismount the child component. Toggling it with initial state will yield correct behavior, in that the log function is only called once at mounting time:

Data computed for prop: { example: "This is some example data" }
DataConsumer mounted
DataConsumer destroyed

However, when only the "Reference data in onDestroy?" checkbox is enabled, the log function is invoked an extra during unmounting, which is clear from the duplicate log line.

Data computed for prop: { example: "This is some example data" }
DataConsumer mounted
Data computed for prop: { example: "This is some example data" }
DataConsumer destroyed

The extra invocation of the log function directly corresponds to where in the onDestroy function the property's value was used. For example, you can move it below the console.log and the above output would be rearranged.

If both checkboxes are enabled (i.e. the template somehow consumes the prop) then the behavior returns to normal.

Logs

No response

System Info

Google Chrome 130.0.6723.70
Svelte 5.1.4

Severity

blocking an upgrade

[trueadm]

This is by design. What's happening here in your example is that Svelte sees log(data) in your template here:

<DataConsumer data={log(data)} {consume} {useDataInDestroy} />

... and it wraps it in a derived signal. That derived belongs to the {#if} block, and when you toggle the block, it will destroy any derived created inside it when the content goes away. Given we've flagged the derived as destroyed, it will no longer be connected to the reactive graph as the {#if} block no longer exists. That means any future reads of that derived will always execute the function inside.

We have to do that as using the last value of derived would not be stable, as it's dependencies inside might have changed – and given it's been destroyed, and isn't part of the reactive graph, the dependencies aren't alive anymore.

This should be fine though, as deriveds are meant to be pure and free of side-effects. So doing things like logging etc are technically side-effects and you shouldn't rely on how many times a derived can, and will fire.

However, I think there might be something we can do to improve this case for legacy mode. I'll investigate.

[wildyaboku]

Thanks for the clarifications @trueadm!

To be clear, the log() function is only used to demonstrate the problem here, but is not required for the behavior to cause errors. Here's an example that caused an error in my SvelteKit app after upgrading to Svelte 5:

<script>
	import { LinkedData } from '$lib/components/LinkedData';
	export let data;
</script>

<LinkedData
	data={{
		'@type': 'ItemList',
		itemListElement: data.results.items.map((post) => ({
			'@type': 'BlogPosting',
			headline: post.title,
			url: post.link,
			datePublished: post.date_gmt + 'Z',
		}))
	}}
/>

The error was caused when I navigated away from this page, if the new page didn't have a <LinkedData> (so it was being destroyed). In that case, because <LinkedData> matches the two rules described in my initial post, data became undefined yet it still tried to evaluate the data.results.items.map() call.

Is that still intended behavior? If so, does that mean I should be doing this logic using $effect or something different?

[trueadm]

So I've put up #14043 which should fix this for Svelte props.

However, looking at your code above, if data can become undefined, surely you should guard against this in your logic?

<script>
	import { LinkedData } from '$lib/components/LinkedData';
	export let data;
</script>

<LinkedData
	data={{
		'@type': 'ItemList',
		itemListElement: data?.results.items.map((post) => ({
			'@type': 'BlogPosting',
			headline: post.title,
			url: post.link,
			datePublished: post.date_gmt + 'Z',
		}))
	}}
/>

Then in your onDestroy you should handle the fact that itemListElement might be undefined too? Another thing you can do is manually hoist your prop value into the component body, rather than have it part of the {#if} block so it doesn't get destroyed.

[wildyaboku]

I did some further digging (in SvelteKit) and actually, it seems like the problem is a little less straightforward.

What's actually happening is that, when the prop is re-evaluated an extra time during destruction, SvelteKit has already replaced data with a new object from the newly loaded page's +page.ts file. The data is not what's undefined, it's actually the results property within it.

Uncaught TypeError: Cannot read properties of undefined (reading 'items')
    at +page.svelte:39:16
    at update_reaction (chunk-YKVIHVK6.js?v=aaf537a7:1714:23)
    at execute_derived (chunk-YKVIHVK6.js?v=aaf537a7:1098:15)
    at Module.get (chunk-YKVIHVK6.js?v=aaf537a7:2000:17)
    at get data (+page.svelte:48:36)
    at chunk-RJV3IGOO.js?v=aaf537a7:3082:14
    at update_reaction (chunk-YKVIHVK6.js?v=aaf537a7:1714:23)
    at execute_derived (chunk-YKVIHVK6.js?v=aaf537a7:1098:15)
    at get (chunk-YKVIHVK6.js?v=aaf537a7:2000:17)
    at getter (chunk-RJV3IGOO.js?v=aaf537a7:3087:19)

This means regardless of whether or not I guard against results being undefined, if the new page has its own results property with a different data type, I can still encounter errors in the above example.

I tested this by having the newly loaded page provide the data { results: {} }. The error message changed accordingly, complaining that items was undefined this time (reading 'map').

It just seems like props are evaluating when they shouldn't be. I don't know that I can always reliably guard against it, and that seems like a band-aid.

Another thing you can do is manually hoist your prop value into the component body, rather than have it part of the {#if} block so it doesn't get destroyed.

Indeed, that will fix it. However, the issue is only present when the prop is not used in the component body, so the if statement was just for demonstration. My <LinkedData> component is producing these errors solely because it does not use the prop in its body at all, it only uses the data during mount and destruction - it behaves exactly like the REPL when "Reference data in onDestroy?" is checked.

[trueadm]

Well hopefully, #14043 will resolve this issue for you.

It just seems like props are evaluating when they shouldn't be. I don't know that I can always reliably guard against it, and that seems like a band-aid.

This turned out to be a bug after all!