Surgically update objects without causing mass reactivity

[purebordem]

Is your feature request related to a problem? Please describe.
Updating a key in an object results in re-firing all reactivity associated with that object, even if the associated reactivity did not specifically reference the specific key in the object that was changed. Any update to an object, even if the exact same data currently in the object, will also cause a re-fire. This does not happen with basic variables.

Describe the solution you'd like
Only fire reactivity associated with the specific key that specific key is updated.

Describe alternatives you've considered
Have tried to develop a custom store to handle surgical updates, but currently cannot determine a valid method.

How important is this feature to you?
Rather important. I need to maintain state sync between multiple clients and the server and passing it back and forth as an object would make things much more straightforward. Currently resorting to using basic variables.

Additional context
REPL demonstrating object reactivity behavior vs standard variable.

https://svelte.dev/repl/8661837c43214b0e941661ab7eebac1d?version=3.19.2

Other
I may have a fundamental mis-understanding on how the reactivity works and what is possible. That said, I really like the way it feels to write Svelte and the object reactivity behavior currently feels counter-intuitive.

[shirotech]

I think you can try setting the immutable option to true which should disable the check for mutating objects.

[purebordem]

@shirotech I tried toying with that today and can't seem to get immutable to delivered the desired behavior either. It really seems like the reactivity is strictly at the object level. Change one thing, it re-fires it all.

[raythurnvoid]

As a workaorund you can try this:

$: prop1 = obj.prop1;
$: console.log("This will fire only on prop1 change", prop1)

[purebordem]

As a workaorund you can try this:

$: prop1 = obj.prop1;
$: console.log("This will fire only on prop1 change", prop1)

Neat idea. I ultimately ended up creating a custom store using lodash that implemented the required functionality. Still would be nice for it to be native without need for a custom store.

[student020341]

Hey @raythurnevoid I found a scenario where this doesn't work. Or if you could help me with the workaround I would appreciate it! If one of the object props is an array, the update refires for another prop being updated. See here:

https://svelte.dev/repl/69a716924f37430ea28fafad92b2debe?version=3.32.3

In the console, you can see the event firing when the string prop is updated even though the array prop is the one being watched. Or is it expected that the workaround will only work for a flat object of simple properties? Google brought me here because I'm facing an issue like this now.

edit: A little more testing info

in that repl, you can change scales to a number or string to see the issue go away. If you make it an array or object the issue is present.

[raythurnvoid]

@student020341 The behavior is correct, the fact is that Svelte (but also other frameworks) cannot know if a prop of an object or an item of an array is changed since it should perform a deep check that is bad for performance. As a workaround for this problem Svelte by default chose to assume that the variable has been changed even if it's not.

To prevent this you can use <svelte:options immutable={true} />.
This will tell Svelte to run reactive code only when the instance of a variable is changed. (To understand each other, an instance of a variable is updated when this check return false: newVal == oldVal).
In case of objects and arrays, to update the instance you must re-assign and re-create the variable. Eg: tuna.scales = [...tuna.scales].

[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.