Svelte 5: resurrect <svelte:options immutable /> or provide alternative

[peterkogo]

Describe the problem

I'm trying to render a list of components based on an array. The performance implications of using deeply reactive state are unfeasible, thus opting for either $state.frozen or stores is the only option.

However, invalidating these deep objects on every change undoes most of the speed gains provided by the faster signal logic, especially with more complex components. An incomplete remedy for some of these issues might be to add additional equality checks, but the greater implications remain.

In Svelte 4 this was solved by <svelte:options immutable />, which is not needed with the $state rune anymore but working with bigger data structures and immutable state it remains useful. I don't agree with the suggestion made by @dummdidumm to add $derived at the right places , as it is an absolute boilerplate factory and a footgun at the same time.

Describe the proposed solution

I would much rather use the prop barrier of a component with <svelte:options immutable /> as an easy way to fence off all potentially expensive updates.

There might be a way to determine if the signal update originated from an immutable source ($state.frozen, Map etc.) and apply the equality checking right away — but I feel like this just adds a layer of hidden and uncontrollable logic and might be quite the performance hog for big objects.

Importance

would make my life easier

[dummdidumm]

You can do this:

<script>
  const props = $props();
  const { foo, bar, baz = 1 } = $derived(props);
</script>

...which means that the given properties are not firing if they are equal to the previous one. Given that you would have to add some additional code either way, I think reusing existing APIs is the best approach here. Does that satisfy your use case?

[peterkogo]

This is the answer, thank you! It did not cross my mind that it is that easy.