Function bindings are not deeply reactive

[AgarwalPragy]

Describe the bug

When using function bindings, the binding setter is invoked only when the bound property is "replaced".
If the bound property is a $state and is updated internally, the binding setter is not invoked.

This can lead to subtle bugs since the state & UI reacts correctly thanks to the deep reactivity of $state - just that the binding's setter is not invoked

Reproduction

https://svelte.dev/playground/eb92a6bcf6a84b99a31d9e5e15fc6815?version=5.46.0

App.svelte

<svelte:options runes />
<script lang="ts">
	import Component from './Component.svelte'
	
	let visibility = $state({red: true, blue: true})
</script>

<pre>{JSON.stringify(visibility, null, 2)}</pre>

<Component bind:visibility={
	() => visibility,
	(v) => {
		console.log('setter called')
		visibility = v
	}
} />

Component.svelte

<script lang="ts">
	let {visibility = $bindable()} = $props()

	function toggleDeep() {
		// the following updates the state without invoking the binding setter
		visibility.blue = !visibility.blue
	}

	function toggleShallow() {
		// the following updates the state and correctly invokes the binding setter
		visibility = {...visibility, blue: !visibility.blue}
	}
</script>
<button onclick={toggleDeep}>Toggle Deep</button>
<button onclick={toggleShallow}>Toggle Shallow</button>

Logs

System Info

svelte: 5.46.0
runes enabled

Severity

annoyance

[sillvva]

The binding is deeply reactive in that the parent state is mutated correctly by the child component. The main issue here is that the setter function is not called when state is mutated. This is more of a docs issue than a bug. The setter function, as you've already realized, only applies when the prop is reassigned.

If you really need to call a function in the parent whenever the state is mutated, then the recommendation would be to use a callback prop.
https://svelte.dev/playground/bcd673360be045228ff3cf74bc7e4ed1?version=5.46.0

[AgarwalPragy]

The binding is deeply reactive in that the parent state is mutated correctly by the child component. The main issue here is that the setter function is not called when state is mutated. This is more of a docs issue than a bug. The setter function, as you've already realized, only applies when the prop is reassigned.

If you really need to call a function in the parent whenever the state is mutated, then the recommendation would be to use a callback prop. https://svelte.dev/playground/bcd673360be045228ff3cf74bc7e4ed1?version=5.46.0

Please correct me if I'm wrong - function bindings are syntactic sugar that reduce the need for callback functions.

Example

If you want to tie some child state to the parent state, just use a binding.

<script>
    // Parent.svelte
    import Child from './Child.svelte'
    let value = $state(0)
</script>

<Child bind:value />

<script>
    // Child.svelte
    let {value = $bindable} = $props()
</script>

<input type="text" bind:value />

But if you later want to modify the parent to add validation, just use a function binding, without having to modify the child

<script>
    // Parent.svelte
    import Child from './Child.svelte'
    let value = $state(0)
</script>

<Child bind:value={ () => value, (v) => (value = validate(v)) />

<!-- Child.svelte does not have to change!  -->

The issue is that function bindings work well for surface-level state, but the bindings don't run correctly with deeply nested state. If both the parent & child are forced to change when validation is needed, it defeats the purpose of function bindings.

It also means that the deep, fine-grained reactivity of svelte is not available across all features.

Yes, documenting this behavior will help others not fall into the same trap, but I believe there's an opportunity for a QoL improvement here.

Please reconsider. 😄

[7nik]

When you do visibility.blue = !visibility.blue there is no reason to sync visibility because it is still the same object.

[dangodai]

It also means that the deep, fine-grained reactivity of svelte is not available across all features.

Actually, I think it demonstrates that deep, fine-grained reactivity is working. Svelte's reactivity system responds to the properties of your object changing despite the object reference not changing.

> let a = { value: 1 }
> let b = a
>
> a.value = 2
2
> b.value
2
> a = { value: 3 }
{ value: 3 }
> b
{ value: 2 }

This is just how Javascript works. The setter for visibility is called when the value of visibility changes. Changing properties on visibility doesn't change its value as the value isn't the object itself, but a reference to the object.

The issue is that function bindings work well for surface-level state, but the bindings don't run correctly with deeply nested state. If both the parent & child are forced to change when validation is needed, it defeats the purpose of function bindings.

It sounds like what you really care about here is validation before setting values. What you are asking for would be a handy way to do it, but it doesn't make sense with how JS works. It would be unexpected behaviour.

As other's mentioned callbacks is one way to solve the problem. Another option (depending on how complex your objects are) is to use a class/object with setters that call your validation. I'm curious if you could abstract out that approach using a nested Proxy inside of $state to intercept writes or if that's incompatible with svelte.

[AgarwalPragy]

It sounds like what you really care about here is validation before setting values. What you are asking for would be a handy way to do it, but it doesn't make sense with how JS works. It would be unexpected behaviour.

That sounds too conservative.

In Svelte 4, reactivity was shallow. You were forced to do

items.push('hello') // doesn't trigger reactivity
items = items // triggers reactivity

... and it was correct, because "that is how javascript works".

Still, not having deep reactivity was a constant annoyance, so it was fixed in Svlete 5. The lack of deep reactivity for function bindings falls in the same category, and should be fixed as well.

And to "how JS works" I say

WE'RE A COMPILER, MOFOS -- Rich Harris

[7nik]

Functional and usual bindings work the same way - see REPL.

There is no reason to sync a value when it does not change but mutates. It is still the same object.

I'm closing this as it has become a pointless discussion, and I don't really see what should be added to the docs. It's kinda obvious that syncing doesn't happen when the value is just mutated and not reassigned with another value.

[AgarwalPragy]

Sad.

This basically handicaps function bindings to only be useful for shallow state. For deep state, you've have to fall back to effects or callbacks.

There is no reason to sync a value when it does not change but mutates. It is still the same object.

Reactivity on mutation, not just assignment, is one of the core features of Svelte 5. Somehow it is being ignored here.

[dangodai]

items.push('hello') // doesn't trigger reactivity
items = items // triggers reactivity

... and it was correct, because "that is how javascript works".

I don't think that's a good example. That was a workaround, not how Javascript works nor was it how people typically write Javascript. The way Svelte has changed since then is much more standard.

As someone not dealing with your current problem, I would say that I would be both surprised and extremely frustrated if the setter was called for a mutation, because the value has not changed. It goes completely against expectations.

Consider the following:

const bar = {
  _foo: {
    value: 1
  },

  set foo(newFoo) {
    console.log("set foo()");
    this._foo = newFoo;
  },

  get foo() {
    return this._foo;
  },
};

bar.foo.value = 2;

Essentially what you are asking for is for bar.foo.value = 2; to call the setter with the log.

[7nik]

The binding only syncs the value itself. It doesn't care whether it is an object or whether it is reactive.

For deep reactivity, should be used $state or a $stateful class. In some cases, a getter can be used.