feat: allow &str and String conversion for Option<Html>#4020
feat: allow &str and String conversion for Option<Html>#4020Madoshakalaka merged 2 commits intoyewstack:masterfrom
Conversation
|
Visit the preview URL for this PR (updated for commit 1c61b6e): https://yew-rs-api--pr4020-allow-option-string-sjgkwf5h.web.app (expires Tue, 10 Mar 2026 13:43:50 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Benchmark - coreYew MasterPull Request |
Size ComparisonDetails
✅ None of the examples has changed their size significantly. |
Benchmark - SSRYew MasterDetails
Pull RequestDetails
|
|
thanks! can you fix the macro output comparison tests? |
|
This is a breaking change because bare #[derive(PartialEq, Properties)]
pub struct Props {
pub title: Option<Html>,
}
// bare None without type annotation
let _ = html! { <Foo title={None} /> };On master: because For reference, we already have broken This PR will make it "uniformly broken" for all three.
@ctron do you have any opinions? |
|
The easiest way is to use the #[prop_or_default] directive for This way, if you just leave out the prop: <Foo />, you get None for title and you can do stuff with the value. Otherwise, since you're not designating #[prop_or_default], there is an argument that you should be passing everything explicitly anyway, so Option::<Html>::None is not that bad, but ymmw |
d247e3b to
318392c
Compare
|
@Madoshakalaka I dont have the 1.84 Rust can you run the trybuild command for me pwetty pwease |
|
I don't see any anomaly. will merge when CI passes. |
Description
Add the following cases to
impl_into_prop_value_via_display!:Add the following cases to
impl_into_prop_value_via_attr_value!:This allows something like this to compile:
This is different from something like
because based on my understanding, #[prop_or_default] with no parameters passed still create h1 in the DOM but empty, whereas with
Option<Html>Resolves #3449
Checklist