Changing how values assigned to attrubutes work

[FoHoOV]

I'm really excited to hear your thoughts on this—whether you agree or disagree and why.

Svelte offers a declarative approach to describing the UI. For example, we write:

<p> {text} </p>

From this, I deduce that the innerHTML of this <p> element always matches the value of the text variable. Similarly, we can write:

<p class={someClasses}> {text} </p>

This tells me that the innerHTML of the <p> element always matches the text variable's value, and the class attribute will consistently reflect whatever the someClasses variable contains. The class attribute only changes if, and only if, someClasses changes. It's very straightforward.

I believe this principle should apply to all attributes. For instance, let's consider the value attribute:

<script>
    let hardCodedFalse = $state(false);
</script>

<p>
    It should never be checked because "checked" is always set to false.
</p>
<input type="checkbox" checked={hardCodedFalse}>

Upon reading this, I would conclude that the checked status always reflects whatever hardCodedFalse holds. If, for any reason, it changes, then the checked attribute should also change (similar to the class attribute, etc.). This is not how it is handled right now, checkout this repl to see what I mean.

This logic should hold unless I explicitly bind the value to that variable:

<script>
    let checkBoxValue = $state(false);
</script>

<p>
    This can alter the checkBoxValue.
</p>
<input type="checkbox" bind:checked={checkBoxValue}>

Even then, I would say that the checked attribute should always reflect whatever value checkBoxValue holds, but now, this input can also modify its value.

Implementing this would be a breaking change, but could it be worth it?

I'm eager to hear your thoughts on this!

[brunnerh]

I do not understand this.

If you pass in a value (checked={something}), then it will update the element whenever the source changes.
Your REPL also does not demonstrate otherwise.

A simple example showing this.

The only case in which this might not hold is when you try to assign a value that is invalid for the given property. The value will then be forced to the correct format or be ignored.

[brunnerh]

There are cases where you don't care about desyncs and a bind: is actually a bad sign:
Namely when trying to make a form work without JS.

Usually here you just set the initial value and the rest is up to the user. If bind: is used, it generally involves some conditional logic that will not work if the JS failed to load or at worst leave the form in an invalid state from the start.

[Prinzhorn]

I see, I'm not using Kit/SSR, so never thought about that

[FoHoOV]

You sure about that? in ssr the inital value is set, even if JS fails to load in csr, it doesn't matter.

[brunnerh]

All depends on the implementation, e.g. sometimes people program forms that show and hide fields depending on inputs/selections in different fields. Such forms completely break down if there is no JS, even if the initially visible fields are of course filled correctly.

[FoHoOV]

How is this related? I might be stupid but I really don't get your point here :( If this can't be enforced, then I love prinzhorn's idea to at least have a warning "THAT IT MIGHT NOT BE WHAT YOU INTENDED TO DO, YOU MIGHT WANT TO BIND:XXX" (for value attributes for instance)

[PatrickG]

This tells me that the innerHTML of the

element always matches the text variable's value, and the class attribute will consistently reflect whatever the someClasses variable contains. The class attribute only changes if, and only if, someClasses changes. It's very straightforward.

This is not quite true.
If you change the innerHTML of that <p> tag, it would be not in sync.
The same happens if you change the class attribute somewhere else (document.getElementsByTagName('p').map(p => p.className = 'lol')).
Of course, you should avoid doing that.

Using bind: is simply a way to tell svelte to listen to input (or in some cases to change) events, and sync the variable when those happen.

[FoHoOV]

Thanks for your reply! I do agree, there could be places when changing this value cannot be SEEN by svelte (although im not sure svelte knows about it or not) and they are mostly not svelte-like. Even in react I can mutate the markup by using a ref and direct HTML manipulation which is not react-like so it doesnt actually matter to me. Maybe, I mean maybe, these attributes should be just like $derived rune and what it does: some-attr=some-var turns into htmlElement.someAttr=$derived(someVar), and even to have backwards compatibility we can introduce a new prefix: derived:value={someVar}. This way I would know IT CANNOT CHANGE outside of the scope of this assignment and be more explicit. What do you think? 🤔

[david-plugge]

I don't think there is a difference between now and what you are looking for. The attribute value behaves like derived already.