Svelte 5: disallow fallback values for bindings

[Rich-Harris]

Describe the problem

More of an anti-feature request: we resolved to disallow fallback values for bindings in runes mode. They're confusing, and a source of bugginess and implementation complexity

Describe the proposed solution

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE42PwWrDMBBEf2URhTg02M1VtQ0hn9H0EMtrqkaWhLQuFKF_ryyFNKU9lD2NtDP7JrBJKvSMvwSmzzMyzg7Wsh2jT7sK_4GKMGlvFifWl9YLJy31Jw0gZ2scwfFNqhEmZ2bY1E1WdTFunk86DSkkMMM7CoIOHjydCasAwiyaODxB3Ka9trklJ1EyB6lHfjU26aO1fSiyzubYNrZPdLMZ5SRxZJzcgnF3K5Nj_lenUIZvznvANAncOmN99Rt2WIiMBqOFkuLShWoLXQ9hzbynhccO9skcYz6Xlz2Hn43W7JL3R7HX-AWtI2YRsQEAAA==

Alternatives considered

n/a

Importance

nice to have

[Malix-Labs]

It seems that the "proposed solution" REPL is instead the "proposed code causing error REPL" about the error

ERROR: Cannot use fallback values with bind:

I also made a simpler one

---

However, on latest Win11 VScode, I only get the error too late, in the console when running the vite dev server, and not with the usual Error: 500 internal server error view

[Malix-Labs]

Also @Rich-Harris, can you provide links for the discussions about

we resolved to disallow fallback values for bindings in runes mode. They're confusing, and a source of bugginess and implementation complexity

please ?

I imagine the confusion could come from their misleading behavior compared to other framework (see #9764 (comment))

I personally think that instead of getting rid of fallbacks values entirely, we should apply the proposed solution in #9948.

It would both more intuitive (same functioning that other framework) and easier than having the boilerplate

$effect(() => { 
	if (propName === undefined) {
		propName = propNameDefaultValue
	}
})

for each prop (which also have the big downside that propName still wrongly have undefined as a possible type)

[harrisi]

Huh, I'm actually quite confused by this as well. The docs for Svelte 4 say that bind: is used so data can flow from child to parent, but if the child can't decide what the data should begin with, what's the point?

At the same time, the workaround is just setting the default immediately after the $props line: REPL.

Note that in App.svelte, count must be $state(), although the value given to it doesn't matter.

There's some additional weirdness here, where the child component has to set the default values if it wants to ensure correct operation, or manually check the types, as far as I can tell: REPL.

Maybe that's just a REPL issue or a bug, though. I'm not convinced of anything right now because I'm not quite sure I understand why this change was made.

[hasinoorit]

It is wired, child component can change the value but can not have default value. It will force us to add some boilerplate for some use-cases. 👎

[dm-de]

WE SHOULD have default values for props, as it is both more intuitive (same functioning that JavaScript functions parameters default value) and easier than having the boilerplate

Here is one more problem:
Today, we have generally no default values (like in function) - this values are initial (like in class constructor).
This is true for svelte 3-5. But any other big framework (react, solid-js, vue) has the ability to define real default values.
So, if you wish svelte-like "default" values, you may not get what you expect.
See: #9948

I suggest to add a smarter ability to set default values.
Today, you must use this:

//Svelte 4
$: if (value === undefined) value = 123

//Svelte 5
$effect(() => {  if (value === undefined) value = 123  })

Because, Svelte is a compiler - it should add above code automatically, if we write this:
let { value=123 } = $props()

[mjadobson]

Or alternatively, to set when null or undefined:

let { propName } = $props();

propName ??= propNameDefaultValue

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE42PUWvDIBSF_8pFBm1ZSdpXFxNGf8ayh8YYZmdU9KYwxP8-o1032B6G-HDuPffwnUAmqYQn9CUQfZ4FoeTZWrIn-GFX4a9CoUjam8XxddJ47qTFttcAcrbGIZzepBphcmaGTVVnVZXDzVOv00MlEMxwERyBwYPHM4rtLu2a-p6WRMkZpB7pzVynRWPbUGRXcbNojE1t24Q0m1FOUoyEoltE3N8b5Jz_dSho4QsurnjWGeszXo_rv-26jiVjJqBwPBwg_iowLIhGg9FcSf7OwnYHrIXwHVIKwCODYzqOMRNks6cQfnriml3y_uj6Gj8BYcUIebkBAAA=

[dm-de]

Interesting, but this is a non-reactive class-constructor-like default value
(this is not how it works in react, solid-js, vue)

edit: code updated:

LINK

[mjadobson]

Interesting, but this is a non-reactive class-constructor-like default value (this is not how it works in react, solid-js, vue)

edit: code updated:

LINK

I believe it works the same way as solidjs; you need to use an effect to respond to future prop changes.

Without effect:
https://playground.solidjs.com/anonymous/4fe70729-39a6-4f66-b3c4-40c57c75e413

With effect:
https://playground.solidjs.com/anonymous/b4abc484-b2a9-483c-9c8b-76d2ca63ee68

[dm-de]

in Solid, you use:
const merged = mergeProps({ greeting: "Hi", name: "John" }, props);

in Vue, you use:
const props = defineProps({ name: {type: String, default: 'Anonymous'} })

in React, you use:
const {fontSize = "20px"} = props;

[dummdidumm]

Solid and React don't have a concept for two way bindings, so the comparison is flawed

[Thiagolino8]

Solid and React don't have a concept for two way bindings, so the comparison is flawed

But Vue does have it, so the comparison is valid