Unexpected behaviour with `$state.frozen()` and `$bindable()`

[mjadobson]

Describe the bug

When binding a variable declared with $state.frozen to a child component, reassigning the prop in the child component throws an error. The child component wraps it in a Proxy object, which is incompatible with $state.frozen.

Error: state_frozen_invalid_argument The argument to `$state.frozen(...)` cannot be an object
created with `$state(...)`. You should create a copy of it first, for example with `$state.snapshot`

Reproduction

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE41SPW_cMAz9K4TQwUYNO8no8xloMnUrMnSpO8gW3QgnS4JEX5oK-u-B7PtqcmgzCNITyEfyPQY2SoWe1T8C03xCVrMv1rKC0YtNwO9REbKCeTO7If00fnDSUtvpjuRkjSN4eJJKwOjMBB0rqwWWa2bHNikwHYUEghOHLXzyxAnL0Zk_qLMAg5k11XADMU_huqNx1gNJo0HqweGEmrIcwkJFB5IAZVmmd3HMT6Bc3vAZbiEupeNfdLMVnDAzb8nMMbapzvPppp-JjAajByWH3Tacuont1-OzqdaottPNk4Mq3bY991JDOIPYVDYFrJL1Uot66WDtaxvWO0LVsoJNRshRomA1uRljcbJoyf6oSUn3cFI-leS9wiwvDkUhpn_rjPXZO_kdeqTvkt9LLT7gwM2F6NdovjljzzQHM67S5NcNEXIPnl4UbjtmuRBS_6rhFqcN9MYJdDXc2d_gjZICejXjpmOLCO-cvBwsto8JwV5ySBiy3pkd6vzC2n9QpKEuKRKG7Nm4nX_DcFiPjv6_IJWQ-ys78DO-Amk4BwSyAwAA

Logs

No response

System Info

Svelte 5.0.0-next.216

Severity

annoyance

[trueadm]

@Rich-Harris Seems like a valid issue. However, is it worth investigating with $state.raw on the horizon? For that matter, what should happen with $state.raw here?

[paoloricciuti]

@Rich-Harris Seems like a valid issue. However, is it worth investigating with $state.raw on the horizon? For that matter, what should happen with $state.raw here?

It seems like it actually fixes the problem,I thought that after reassigning a proxy it could've maybe make the properties reassignable but it seems also that is fine.

[trueadm]

@Rich-Harris Seems like a valid issue. However, is it worth investigating with $state.raw on the horizon? For that matter, what should happen with $state.raw here?

It seems like it actually fixes the problem,I thought that after reassigning a proxy it could've maybe make the properties reassignable but it seems also that is fine.

Does it? It looks like the raw object becomes proxied, but that also means the raw object will get mutated when the proxied object does too. That doesn't seem right.

[paoloricciuti]

Does it? It looks like the raw object becomes proxied, but that also means the raw object will get mutated when the proxied object does too. That doesn't seem right.

I see the opposite...even if you mutate the object in the child it's not reflected anywhere...am i missing something?

[trueadm]

Does it? It looks like the raw object becomes proxied, but that also means the raw object will get mutated when the proxied object does too. That doesn't seem right.

I see the opposite...even if you mutate the object in the child it's not reflected anywhere...am i missing something?

If you press mutate on the inner component and then increment on the parent, the parent gets a random number – that's not right – it should be 1.

[Rich-Harris]

Fixed by #12808 — demo

[trueadm]

Fixed by #12808 — demo

Does it though. See this example @paoloricciuti posted above. If you press mutate on child component, and then increment on the parent, you should get 1, no?

[Rich-Harris]

No. You've mutated data.count, so any subsequent data = { ...data, count: data.count + 1 } should include the mutation.

There is a problem though — resetting via bind causes a proxy to be created, meaning that while the first mutation has no visible effect, the second one does. We should avoid calling $.proxy in the child when resetting the prop (though we do want to create a proxy if no prop was provided, because that's just how bindable props work, unless we add a $bindable.raw rune which feels like overkill). Will look into it on that PR.

There's also no indication that you mutated a raw object, but that's just how raw state works, and we previously decided against trying to intercept those mutations to warn on them

[paoloricciuti]

There is a problem though — resetting via bind causes a proxy to be created, meaning that while the first mutation has no visible effect, the second one does

Uh something has probably changed in the new PR because in the old one the second mutation was not showing up

Maybe we should check in the prop getters if the state is raw or not? Because from the child component we don't have a way to check it right?

[Rich-Harris]

It works correctly as of the most recent commit. Basically we never call $.proxy in the child component when updating a prop, we leave that to the prop itself

[Rich-Harris]

merged #12808, so I'll close this