Reassigning bindable prop will lose reactivity in parent

[rogerfar]

Describe the bug

When you pass a $state with an object as a $binable prop, and you re-assign that prop to a new object in the child, the parent will not pick up on the change.

Reproduction

https://svelte.dev/playground/c67f404b51e24509ab99a256950ffd7a?version=5.28.2

Click Add a few times, both $inspects will show the correct list, but when clicking Remove, only the Component.svelte will output, App.svelte will not be aware of the change.

Logs

System Info

System:
    OS: Windows 10 10.0.19045
    CPU: (24) x64 13th Gen Intel(R) Core(TM) i7-13700       
    Memory: 31.60 GB / 63.79 GB
  Binaries:
    Node: 22.15.0 - C:\Program Files\nodejs\node.EXE        
    Yarn: 1.22.22 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 11.3.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (135.0.3179.85)
    Internet Explorer: 11.0.19041.4355

Severity

annoyance

[Ocean-OS]

You have to bind: the list in the parent component.

[rogerfar]

Ok darn that makes sense. I completely overlooked that fact because it works when manipulating the object.

Is this then intended behaviour? Should that relation not be immutable if there is no explicit bind set?

[Ocean-OS]

If the prop is not binded to, then the prop acts like a $derived in the child component. Any writes to it would be overridden if the parent component updates the value of the prop.
To be honest, I'm not sure why mutating an unbound prop is allowed, since that seems like a bad practice.

[rogerfar]

That makes sense, and I agree, maybe we could throw a warning saying we're trying to manipulate a $bindable object that doesn't have bind.

But is there a use-case where we want $bindable on the prop, but not use bind:?

[Ocean-OS]

It's just however the developer of the parent component chooses to use the child component. If the parent component doesn't intend to use bind, but their prop's value is changed, that wouldn't be expected behavior.