-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Inconsistent clone() requirement when passing Classes to HTML elements vs. components (#3589) #3931
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
Inconsistent clone() requirement when passing Classes to HTML elements vs. components (#3589) #3931
Conversation
Benchmark - coreYew MasterPull Request |
Benchmark - SSRYew MasterDetails
Pull RequestDetails
|
|
Visit the preview URL for this PR (updated for commit 02efc44): https://yew-rs-api--pr3931-fix-classes-implicit-y7ul53kb.web.app (expires Wed, 29 Oct 2025 13:48:06 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Size ComparisonDetails
✅ None of the examples has changed their size significantly. |
adds an additional candidate to the impl block, which is fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. If implicit-clone ever gets a trait for Into that automatically uses ImplicitClone for references, that would make this less of a manual effort to keep track of the impls.
Thanks for the PR 🎉
There is an inconsistency in how the Classes type is handled between component props and standard HTML element attributes.
When passing a Classes prop to a Yew component, it can be passed directly without needing to call .clone(). However, when passing the same Classes value to an HTML element's class attribute, the compiler fails with a trait bound error, forcing the developer to explicitly call .clone().
This behavior is unintuitive and inconsistent, as one would expect the html! macro to handle both cases similarly.