Open quinnjr opened 3 years ago
Hey @quinnjr, thanks for taking the time to open this PR! It is on my shortlist to get it reviewed and merged.
@thedodd thank you! Also, when you have a chance, can you re-run the CI tasks on the pull request? Looks like Github had some network issues while trying to test my commit for fixing the cargo fmt
error.
@quinnjr hello there (3 years later). If you are still interested in getting this work landed, we have a set of beta releases being published for the 0.4.0 line (Yew 0.20 and all). I would be happy to get this work landed and released as part of the beta if you are still interested.
I moved back to using Angular instead of Yew. I'm not much interested in working on this, unfortunately.
Summary
This pull request adds
id
fields to most of theProperty
structs of each component of the library and associated additions of theid
field into the html templates of the corresponding component.Example:
NOTE: The
id
field was already present forModal
s and was thus left untouched.The
id
field was added to each*Props
struct below thepub classes: Option<String>
field with#[prop_or_default]
enabled on eachid
addition.Why so many
id
s?My current legacy code that I am converting from Angular to Yew contains work that used
id
s on components, which I expected to be able to use onybc
elements. I felt it would be beneficial to add the field across the library in a standardized way for those who expect the html attribute to be present.As well, using
id
s in vanilla javascript, such as:is much easier to work with inlined javascript.
Finally,
id
is also a part of the global attributes defined on all html elements per the HTML Living Standard and I felt it was appropriate to define the attribute as common on all components in this library.Contribution Checklist
cargo clippy
andcargo fmt
on code.Cargo.toml
version
field.CHANGELOG.md
.