Binding to store values not working correctly in Svelte 5 about svelte HOT 5 OPEN

From my understanding, I'd say that you're indeed misusing stores, and this is how Svelte 5 fine-grained reactivity works. You're not changing the value of $state itself, but merely mutating the $state object, which doesn't cause an update from the store's point of view.

The reason that it works in Svelte 4, is not because of store updates, but because of the compiler invalidating the whole state prop when you mutate state.checked.

function input_change_handler() {
	state.checked = this.checked;
	$$invalidate(0, state);
}

This makes $: console.log({ Checkbox: state }) works as expected, but comes with a cost of invalidating everything that depends on state, even though the actual value doesn't change (i.e. $: console.log(state.completely_unrelated_property) will also re-run when state.checked is changed, see REPL)

In Svelte 5, the compiler no longer "guesses" what changed, instead moving that to run-time using signals. And since there are no signals on state.checked, nothing gets updated. FYI, converting your example to use $state works as expected.

from svelte.

If the Checkbox component is in legacy mode, it works as expected.

It will cause the state setter to be called in the binding.

$.bind_checked(
  input,
  () => state().checked,
  ($$value) => state((state().checked = $$value, state()))
);

from svelte.

Well, stores are still a supported part of Svelte 5 and they just do not have fine-grained reactivity.
So a case could be made that this should be backward compatible.

A problem probably is that the Checkbox component does not know that the property gets its value from a store. On the App side, access to the store is wrapped in a get/set pair:

Checkbox(node, {
	get state() {
		return $state();
	},
	set state($$value) {
		$.store_set(state, $$value);
	}
});

The setter is currently not invoked. Maybe some metadata could be passed along to make the Checkbox aware that a store is being passed in and that the setter needs to be called, e.g. by proxying the prop. Might be a bit complicated, though.

from svelte.

This looks to be working as expected for runes mode. Svelte 4 doesn't have runes mode, so you're not comparing apples to apples.

I wonder if you remove the usage of runes, does this issue go away? Then it will force the components into legacy mode which eagerly overreads because of the lack of fine grain reactivity. Legacy mode is also more aligned to how Svelte 4 works, so if there's a difference then that's likely a bug we need to fix.

from svelte.

I'd say this works as expected in runes mode, though the behavior is probably a bit surprising at first. I'm wondering if there's a way to warn in this case (in dev mode).

from svelte.