Bind to properties instead of attributes by default

[ranile]

Description

Fixes #1322

TODOs

• Add ability to forcefully bind to attributes

Checklist

• I have run cargo make pr-flow
• I have reviewed my own code
• I have added tests

[mc1098]

From #1322

There are also various Custom Elements (CE) that expect values to be set through properties instead of attributes.
One reason for that is that attributes only support string values, properties allow all JavaScript types (string, number, boolean, object, array),

I think this is something to add to the TODO, the ability to set types other than string to properties.

[mc1098]

So I actually think we can limit the scope of this PR to just swapping over from setting attributes to properties, this should allow us to rip out all the special treatment of value and checked in VTag and the html macro. The one thing unresolved for me is what to do when the property is removed, at the moment you are trying to delete the property which doesn't work and I'm not sure it would be correct even if it did. I don't know whether we try and find the defaultX property for that property or the attribute in order to set the value back to it's default - which makes it feel very much like take from Rust which I quite like but if we can't find anything do we just leave the value as is or set it to NULL?

[ranile]

So I actually think we can limit the scope of this PR to just swapping over from setting attributes to properties

If that's the case, then I guess most of the functionality is already implemented.

The one thing unresolved for me is what to do when the property is removed, at the moment you are trying to delete the property which doesn't work and I'm not sure it would be correct even if it did.

Did you test it? I didn't get to manually testing the behavior so if you could provide a test case for it, that would be nice. I don't see why it wouldn't work

we can't find anything do we just leave the value as is

Leaving it as-is is a bad idea. There are cases where the value must be removed.

or set it to NULL

I think this is the default so we can do that.

[mc1098]

If that's the case, then I guess most of the functionality is already implemented.

Pretty much, though the special treatment of value and checked` can be ripped out here too - or were you thinking this could be another PR after this one?

Did you test it? I didn't get to manually testing the behavior so if you could provide a test case for it, that would be nice. I don't see why it wouldn't work

Yep, and tested it in the browser without Rust and you cannot delete a HTMLElement property. I could add a test case but I don't think removing the property is the correct thing to do regardless of whether it worked or not.

Leaving it as-is is a bad idea. There are cases where the value must be removed.

I think this is the default so we can do that.

In what cases? And when you do - are you expecting the state of the property to reflect what it was on the initial render or just
the default value of that type (empty string, false, etc).

[ranile]

Pretty much, though the special treatment of value and checked` can be ripped out here too - or were you thinking this could be another PR after this one?

I can do it here. I'm not sure which code exactly needs to be pulled out.

In what cases? And when you do - are you expecting the state of the property to reflect what it was on the initial render or just
the default value of that type (empty string, false, etc).

I was thinking of custom elements when I said that. I don't know what the default value should be

[mc1098]

I can do it here. I'm not sure which code exactly needs to be pulled out.

VTag mostly and some in the yew-macro when constructing a VTag - Yew is checking for inputs and treating value and checked in a special way.

I was thinking of custom elements when I said that. I don't know what the default value should be

I just don't know of a scenario where you want to delete an element property, which is why I'm asking :)

[ranile]

@mc1098, after ripping out the special treatment, 3 of the tests fail. The value/checked don't seem to be properly updated.

const inputElement = document.createElement('input')
inputElement.hasOwnProperty('value') // this returns false

The value is set as attribute, not property. Seems like we might need the special treatment after all

[ranile]

There's too much changes happening to justify this PR. It is something for the future