Describe the feature you'd like
html! { <sometag foo=expr></sometag> }sets an attribute foo with the result value of expr
There are some attributes (type, checked, and value) which are automatically passed to the property instead by some hardcoded exceptions.
My suggestion is to always bind to properties for attribute-style parts of html! { ... content } by default.
If a property with such a name does not exist, the binding should be automatically set as attribute.
if (elem.hasOwnProperty(prop)) {
elem.setProperty(value);
} else {
elem.setAttribute(value);
}Explicitly binding to attributes instead of properties should be supported with special syntax.
I do not have a strong opinion about what the concrete syntax should be, but my suggestion would be <sometag @foo=expr> (and also <sometag @foo="literal">)
As the special treatment of checked and value shows, the distinction is relevant and should be properly supported. I think hardcoding exceptions the way it's done with value and checked is not a good solution.
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), some CE expect objects with various fields set as configuration.
For example binding an array of objects to an attribute would lead to <sometag foo="[Object Object Object]">` where all object information is lost, while when passed to a property the original array of objects are received.
Is your feature request related to a problem? Please describe. (Optional)
- Mostly the exceptions hardcoded in Yew for
checked and value, and possible similar future exceptions that would need to be maintained in Yews source code.
- Limits CE support.
I think CEs could be a great companion technology to WASM especially for use cases where FFI is too cumbersome, but also just to make use of the large pool of ready-to-use components.
Describe alternatives you've considered (Optional)
Additional context (Optional)
Previous discussion in #1298
Related discussions for proper CE support in React can be found in
Difference between properties and attributes
Questionnaire
Describe the feature you'd like
sets an attribute
foowith the result value ofexprThere are some attributes (
type,checked, andvalue) which are automatically passed to the property instead by some hardcoded exceptions.My suggestion is to always bind to properties for attribute-style parts of
html! { ... content }by default.If a property with such a name does not exist, the binding should be automatically set as attribute.
Explicitly binding to attributes instead of properties should be supported with special syntax.
I do not have a strong opinion about what the concrete syntax should be, but my suggestion would be
<sometag @foo=expr>(and also<sometag @foo="literal">)As the special treatment of
checkedandvalueshows, the distinction is relevant and should be properly supported. I think hardcoding exceptions the way it's done withvalueandcheckedis not a good solution.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), some CE expect objects with various fields set as configuration.
For example binding an array of objects to an attribute would lead to
<sometag foo="[Object Object Object]">` where all object information is lost, while when passed to a property the original array of objects are received.Is your feature request related to a problem? Please describe. (Optional)
checkedandvalue, and possible similar future exceptions that would need to be maintained in Yews source code.I think CEs could be a great companion technology to WASM especially for use cases where FFI is too cumbersome, but also just to make use of the large pool of ready-to-use components.
Describe alternatives you've considered (Optional)
Additional context (Optional)
Previous discussion in #1298
Related discussions for proper CE support in React can be found in
Difference between properties and attributes
Questionnaire