-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bind to properties instead of attributes by default #1322
Labels
A-yew
Area: The main yew crate
feature-accepted
A feature request that has been accepted and needs implementing
feature-request
A feature request
Milestone
Comments
Thanks for the write up @zoechi, I'm in favour 👍 |
Great, I'm interested in making an attempt to implement this myself but, I'm still very slow with Rust and still busy figuring out how optional attributes could be implemented. So if anybody is interested in this task just go with it. |
No worries, take your time @zoechi, feel free to ask general Rust questions in the discord chat too if it would help. |
5 tasks
3 tasks
mc1098
added
A-yew
Area: The main yew crate
feature-accepted
A feature request that has been accepted and needs implementing
labels
Sep 20, 2021
2 tasks
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-yew
Area: The main yew crate
feature-accepted
A feature request that has been accepted and needs implementing
feature-request
A feature request
Describe the feature you'd like
sets an attribute
foo
with the result value ofexpr
There 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
checked
andvalue
shows, the distinction is relevant and should be properly supported. I think hardcoding exceptions the way it's done withvalue
andchecked
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)
checked
andvalue
, 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
The text was updated successfully, but these errors were encountered: