Svelte 5: store updates trigger component prop changes that didn't with 4

[CaptainCodeman]

Describe the bug

Setting a component prop to a store value causes the component prop to see a change with 5 when it didn't with 4.

i.e. it appeared to be deduped with 4 but isn't with 5

Reproduction

Svelte 4: https://svelte.dev/repl/d43370affcf9403b9a5566a9e9849da8?version=4.2.15

Toggle triggers a change in the component, Update doesn't (prop value stays the same).

Svelte 5: https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE41SQW6DMBD8ytaKFJAQ3BEgVflCeyo9ELJEVo3XwkuayvLfK-yIpEkPOa09npkd7dqJQSq0ovxwQncjilK8GiMywT9mudgTKkaRCUvz1C9IZftJGm5a3bIcDU0MDr4nyd1eIXgYJhphG3WFZZpwe0Pd0WhIo-YLLy9WJI-aha1b7klbhqCHevVPHJw6NWMJQ6csgk8je5h1z5I0MB2PCpMU3AK3HAzy2Rw6xuQMdQNXi5dzHk7g08WG_Z3XRfWU16NVVVwHpav9zEwaSJe9kv1X7WJQ37yFWhWR0PxHjR198x7qDbXVbhNDheYhf3WdcADrvxQoGpGJkQ5ykHgQJU8z-mzd_Sp-9gfgOaxV4aVdHOGmhGV_pDBXdEzCS3o3EhcDPab59L-vjIN4lQIAAA==

Update now triggers a change of the prop value, even though the value hasn't actually changed (see console log)

Logs

.

System Info

System:
    OS: macOS 14.4.1
    CPU: (6) x64 Intel(R) Core(TM) i5-8500B CPU @ 3.00GHz
    Memory: 1.83 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.0.0 - ~/Library/pnpm/node
    npm: 10.5.1 - ~/Library/pnpm/npm
    pnpm: 9.0.6 - ~/Library/pnpm/pnpm
    bun: 1.0.0 - ~/.bun/bin/bun
  Browsers:
    Brave Browser: 123.1.64.113
    Chrome: 124.0.6367.119
    Chrome Canary: 126.0.6456.0
    Safari: 17.4.1
    Safari Technology Preview: 17.4
  npmPackages:
    svelte: ^5.0.0-next.123 => 5.0.0-next.123

Severity

blocking an upgrade

[paoloricciuti]

It's actually more broad than that...is just that by changing the reference to the base object you are actually invalidating the whole effect. The same happen with simple reassignment

https://svelte.dev/repl/e9ba4f7ea0e74285a3b66ebfd98a7cae?version=4.2.15

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE1WOQQrCMBBFrzIMLlIo6rq2Bc9hXNQ4lWCclGYiSMjdpVFRl_OZ9_5POFpHAZtDQh5uhA3upwlrlMe0HOFOTghrDD7OZknaYGY7Sa9ZiyMB4yMLdLAKMgipBPfBRWpgC7naaV7eVjSOZESpCroe0hJpMZ6Dd7R2_qKKY13AwkhB2823ittTFPEMno2z5tolVXV9UX0GpHfxjyxrzrksTf9pu3npeqzx5s92tHTGRuZI-ZifGKSDjBQBAAA=

However i wonder if this should just be considered a breaking change, personally i don't have a good idea of how this could work with signals. I'll thinker a bit about it while we wait for maintainers to show up.

Scratch that i'm an idiot and svelte 4 actually has the same behavior in this case.

[CaptainCodeman]

Yes, any update to the store, even another property on an object, can end up triggering a prop change in a component when its values haven't really changed.

IMO it's a breaking change because it can easily alter the behavior of existing components when running under 5 vs with 4, even when runes are not used.

Although it's fairly easy to dedupe the changes within a component, those components might be 3rd party packages.

Update: I think my comment overlapped your edit - we're saying the same thing.

[CaptainCodeman]

In case anyone needs a temporary fix:

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE41SQYrcMBD8Sq9YGBsG-25sQ0iekJziHLx2e9BGloTUnkwQ-nuQ5MizkyXsSVJTXVXqascWLtCy5rtjclyRNeyT1uzM6LcOD3tFQcjOzKrNTKHS2slwTf0gB-KrVobAwS_DaXwRCB4Wo1Y4pb7akjJ4uoN-VqtWEiXtuKrOlSr1nN4QTwZHwi84bxpNZq_qOVWqVxvwcqBJSUsQ9aDLfgoH11Fs2MAyCovgywObKKB7q1GUiW_Z5ERcSSB1uQgsSnChPFCUqDY9j4TFDboeDpGnWxVv4Mso5B-49q4Pcf1L1dbH6GX7shEpCUo2k-DTz84lo77_Gs-2ToD-PWhS9P23eN5BB-mek6koHv23R2ax2Lk0ueIeWXqoe3Zmq5r5wnFmDZkN_TlvVSb56G7hLa6AwF02jfK5gZCeElgJdSmS9sNoXPL-Pzf7-hxeXu29j1075_awISm-4EwbvIa7QdqMTEZDjHu-fIFkEZ66LoJz9AOFJ3T5c5TWhTLZX24_yHf-8sP_AR9atIi7AwAA

[CaptainCodeman]

Svelte 5 has the same behavior in runes mode - i.e. the prop updates. So if that is an intended change it should be noted as breaking #11400

But for non-runes mode, it needs to behave as 4 did IMO.

[dummdidumm]

Is this something that causes real bugs in practise? I'm contemplating whether or not we should fix this, because it will likely mean loads of extra deriveds (one for each prop) in legacy mode for what I believe is a marginal fix in edge cases.

[gterras]

Is this something that causes real bugs in practise? I'm contemplating whether or not we should fix this, because it will likely mean loads of extra deriveds (one for each prop) in legacy mode for what I believe is a marginal fix in edge cases.

It seems like a situation that would crucially rely on this effect should also have some kind of lifecycle or reactive check to work properly in most cases anyway.

[CaptainCodeman]

Yes, I found it from my first attempt upgrading some apps to 5. It isn't super-difficult to handle the change of behavior within the components but there is a real possibility that some components will break because of it and they might be external components.

[CaptainCodeman]

It seems like a situation that would crucially rely on this effect should also have some kind of lifecycle or reactive check to work properly in most cases anyway.

Not sure what you mean - something relying on the existing v4 behavior?

IMO it's consistent in v4 - setting a component prop to the value it is already set to doesn't trigger a change whether that prop value comes from a reactive variable or a store. I think it would be confusing if components changed their behavior based on how the property value was passed in from being a reactive variable, store, or rune.

[dummdidumm]

Yes, I found it from my first attempt upgrading some apps to 5. It isn't super-difficult to handle the change of behavior within the components but there is a real possibility that some components will break because of it and they might be external components.

Could you elaborate what exactly broke after upgrading, or put differently, how your real component looked like so that it broke?

[CaptainCodeman]

The specific component applied some CSS animations in a sequence when it saw a boolean toggle change (when it hadn't actually changed, but something else in the same store managing the state had).

I haven't tested it with a string value yet but I expect it will affect a deep-zoom photo viewer that relies on the change to a base URL to trigger a reset of the view and cause it to start loading image tiles (where a store could update for other reasons, like registering a 'like').

I need to also test a lazy image component that shows a blur-hash image while the proper image loads as again, the URL changing is the trigger to start the process and the store that has it can be updated for other reasons (e.g. changing sizing / positioning)

It's really anything where the prop-change is a trigger to something happening which is more than simply rendering values into the component template. I don't tend to use it, but could see people fetching data in response to data changing.

Maybe it needs a "strict" vs "simple" configuration setting for legacy mode, where people could start with the strict mode when converting to reduce the number of issues, and switch to the altered behavior as a separate optional stepping stone to moving to native runes mode?

[gterras]

The specific component applied some CSS animations in a sequence when it saw a boolean toggle change (when it hadn't actually changed, but something else in the same store managing the state had).

I haven't tested it with a string value yet but I expect it will affect a deep-zoom photo viewer that relies on the change to a base URL to trigger a reset of the view and cause it to start loading image tiles (where a store could update for other reasons, like registering a 'like').

I initially thought you were passing the store (and meant what you did with createDeduper since this kind of tasks usually already involve storing side data) but reading the example again it's clear that it should be listed as a breaking change especially since it's less intuitive, as in not necessarily creating bugs (although I'm curious to see the animation case) but could easily trigger unnecessary workload in many reasonable implementations.

[CaptainCodeman]

No, it's passing a property value from the store when some other update is made - the deduper was to prevent the update triggering a prop change where there wasn't really any change to the actual prop value itself. The complication is when the component may happen to be deeper within some 3rd party package you import and don't control or you just don't understand why your app is behaving strangely.

The animation is playing enter / leave transitions via switching TailwindCSS classes, based on a toggle property and used in UI components which would suddenly start flickering and behaving weirdly as other properties were set in the stores containing the state. i.e. changing the selected item on a menu would trigger the menu to re-run the open animation when it shouldn't. I fixed it in the component but it could be a gotcha when anyone is upgrading from 4 to 5.

I'm part way through dealing with some separate build issues, but think there are a few other places in my apps that could be impacted by this. Some may not be visible, but the updates could trigger things like Firestore subscriptions to re-fire, which is generally something to avoid ($)