Svelte 5: binding_property_non_reactive when binding to a writable store

[WaltzingPenguin]

Describe the bug

const store = writable({ count: 0 })
let rune = $state({ count: 0 })

<Child bind:form={$store} />
<Child bind:form={rune} />

I would expect the binding to both the store and rune to operate the same in this scenario. It does not however. If <Child /> contains <input type="number" bind:value={form.count} />, the version passing a writable store will warn "binding_property_non_reactive" and changes will not trigger UI changes.

Reproduction

https://svelte.dev/playground/4341cc700cfa4fb6b7795d4ae65a3051?version=5.0.5

Logs

No response

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (20) x64 13th Gen Intel(R) Core(TM) i5-13600KF
    Memory: 45.21 GB / 63.85 GB
  Binaries:
    Node: 20.9.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.1.0 - C:\Program Files\nodejs\npm.CMD
    pnpm: 8.11.0 - ~\AppData\Local\pnpm\pnpm.CMD
  Browsers:
    Edge: Chromium (127.0.2651.74)
    Internet Explorer: 11.0.22621.3527
  npmPackages:
    svelte: ^5.0.5 => 5.0.5

Severity

annoyance

[JetLua]

<Child bind:form={form}/>

// Child.svelte
<input type="number" bind:value={$form.count} />

A slight modification：
https://svelte.dev/playground/4341cc700cfa4fb6b7795d4ae65a3051?version=5.0.5#H4sIAAAAAAAAE3WQT2vDMAzFv4oRhbRQkp1NUhi97bAddpx3SFJlMziysZVuxfi7DydtWffnYqMnS36_F2HQBgPIlwh8cghyFmAL1I65uneuDEc0nLWuDfiX3ltiJA4goV5EaR1rS0H4iTCIaqdIUR16rx3vFOnRWc8iig-vue0MiiQGb0dRLONVYOuxuD7cv2tzOL8oq7k6_17kxQZZDNaPorkuXEdFins7EUtxpyhtFNXV1YCietnZaTrIPNvEfKbZanx4fnosA3tNb3o4rVe5tUmKYAuMnwyS_YRp-09m3_3dpvajc5PbxVqGiRecVfY382xEyrXz1oX1LxiXL641uYlFNtUooGns0CtYGI-tmbCJM0o557Kw1lWevQV7TV9JUqXGGAIAAA==

[trueadm]

As pointed out above, you need to pass the store though without the $ prefix, otherwise you're just passing the value, not the reactive store itself.

[brunnerh]

Is that documented anywhere? (Did not see it in the migration guide)
This works as intended in legacy mode.

[trueadm]

Is that documented anywhere? (Did not see it in the migration guide) This works as intended in legacy mode.

Legacy mode works regardless because it’s not fine grain.

[brunnerh]

Stores are not meant to be fine-grained, but runes mode probably assumes otherwise, it ideally shouldn't, though.
I vaguely remember that there already was an issue relating to stores being passed through props before...

[WaltzingPenguin]

As pointed out above, you need to pass the store though without the $ prefix, otherwise you're just passing the value, not the reactive store itself.

It works just fine for primitives. So, no, Svelte is not just "passing the value" by reference.

JetLua was being helpful and suggested a workaround for this issue, but it is exactly that: a workaround. I could also wrap the value in $state but neither approach should be the blessed path.

Stores are not officially deprecated yet, but if nested POJO are not safe to keep in stores, then they might as well be for all practical purposes.

[trueadm]

So, no, Svelte is not just "passing the value" by reference.

That's because you're passing the store itself which is reactive. As soon as you reference a property of the store, it's no longer reactive unless the store is within scope. So in terms of the runtime, you're just passing the value of object, not the store.

Stores are not officially deprecated yet, but if nested POJO are not safe to keep in stores, then they might as well be for all practical purposes.

The logic for this is on this line:

https://github.com/sveltejs/svelte/blob/main/packages/svelte/src/internal/client/reactivity/props.js#L346

If we remove that condition, then the above examples will work like they do in legacy mode. However, we're then pushing additional runtime to all users even if they might not pass stores in their props. I considered using a WeakMap to associate only certain properties with stores when bound, or another special property that we apply only in runes mode – but it's quite a lot of extra complexity.

Another approach is that we proxify the object when passed to writable if in runes mode, but that seems too invasive.

[WaltzingPenguin]

That's because you're passing the store itself which is reactive.

JetLua passed the store in their example. The referenced example, for primitives, passed 0.

For anyone migrating large codebases, here's a dumb wrapper you can use so you don't have to modify the leaf components: REPL

For the maintainers, this isn't an edge case. Imagine any large, nested object that would get persisted to localStorage/IndexedDB/network. Stores with their convenient set methods were the best way to handle the required update logic. Rewriting sections of code that passed such a store through four different levels of components is non-trivial.

[trueadm]

JetLua passed the store in their example. The referenced example, for primitives, passed 0.

Under the hood, that's not working as you think it is. We do some crazy stuff with bound props to make this stuff work and adding more logic to the props handling is an option, but one that we've tried to avoid where possible.

I'm not arguing their benefits. I think we can maybe do something smart here, leave it with me.

[trueadm]

Let me know how things work out on #13887 please.