Overzealous updating of components when using {#each} on array of objects

[rdb]

There's some awkward behaviour of Svelte that looks to me like a potential performance pitfall, and it occurs when iterating over an array of objects with {#each} and passing an element to a child component. For example:

{#each array as item (item.id)}
  <Item item={item} />
{/each}

The problem is this: if I add a new object to the end of the array, Svelte will update all the Item components, not just the one I added. This is demonstrated in this REPL (open the JS console to see the updates). This doesn't happen when it's an array of strings or numbers.

I think that the function safe_not_equal() is used for this, which never sees objects as equal, even identical ones. While I understand why this would be so in some cases (eg. a = a; should work for objects), it's less clear to me why this should also apply when updating a keyed "each" in this fashion.

I understand that there are several workarounds for this. I could destructure the object, but in my case it's very inconvenient for this component to have to know all the internals of my item model. I could mark the Item component as immutable, and this certainly works as expected, but this isn't very satisfying because this applies to all properties, and I don't want that in my case.

Perhaps there is a good technical reason for it to work like this? If so, I think this should be documented so that others don't trip over this. If not, please consider this my humble request to change this behaviour.

Oh, and thanks so much for creating such a great library! I don't think I'll be able to ever go back to React now that I've tried Svelte.

[Conduitry]

The key on a keyed each is used to control where new items in the array get added (instead of always adding them at the end and then forcing the new data into each component). It doesn't mean that as long as the key is unchanged, any props sent to any child components are assumed to be unchanged. Svelte doesn't know whether you might have mutated any of these objects in the meantime. The behavior for that component, as it is written, isn't going to change.

Being able to specify immutable in the parent instead of in the child has come up before in #1740 but I don't think that's really been looked into at all.

Being able to mark certain props as immutable has probably come up before, although I'm not sure whether there's an issue. It's also not really clear to me how that would work, because a compiled component does lots of comparison checks between things that aren't props, and are instead directly or indirectly computed from various props or from browser events or from other sources - and how do we decide whether each one of these should be a not_equal or a safe_not_equal?

[rdb]

Thanks for the swift response!

So what I'm starting to get is, when I do items = [...items, newItem], Svelte assumes that all the item properties have been modified, because the special semantics of the = operator in Svelte say so?

Perhaps safe_not_equal could allow me to mark objects as immutable somehow, perhaps by allowing me to use Object.freeze() and checking Object.isFrozen(), or otherwise a Svelte-specific flag? If the object is known to be immutable, Svelte would just do an identity comparison.

Failing that, perhaps it would be a useful feature to be able to provide a callback on Item that determines whether the component should be updated when a property is changed from outside the component.

[nous-]

For me, it wasn't clear from the original post that you would NOT have this problem if you spread the props, or passed in each object property separately. Here is a modified version of @rdb 's REPL to demonstrate this.

An example where this came up for me was I had a component that operated in say 3 distinct states, which required different sets of variables for each state. To enforce correctly setting the variables for a given state, I had a single property state that would take a state object that was created through exported functions.

I ended up exporting functions to update the state directly vs exporting functions to generate a state object and pass that object back in via a state property, for a few reasons:

1. False reactions required extra logic to prevent
2. I would have to call an exported function anyway with matched definitions
3. I had no use to modify or store the generated state externally

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rogerfar]

I ran into the same issue today and wanted to just add it as a reference.

If you take this repl: https://svelte.dev/repl/1ce699aa893b4bd983763f75796818fa?version=3.20.1

When you click Change you see it changes the 2nd component, but it will also trigger all the other components.

This is expected because the list variable gets re-assigned, even though it's keyed.

I wonder if there is an optimization that can be made here to either check the references of each element in the array (updating a single element causes the whole array to be updated) or use a smarted update mechanism for arrays.

[mariusnita]

Svelte should provide a way for the user to control the comparison strategy. Something like:

import {equals} from 'svelte';
equals((propName, currentValue, newValue) => /* returns true/false */);

Then you could even do deep equality.

[dummdidumm]

Closing as outdated since Svelte 5 provides more control over how fine-grained things are with runes, likely fixing this (and definitely giving people a way out)