Skip to content

Allow using Option<VNode> in html!() macro #2792

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.

Sign up for GitHub

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

Merged
ranile merged 1 commit into from
Sep 14, 2022
Merged

Allow using Option<VNode> in html!() macro #2792

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions packages/yew-macro/tests/html_macro/html-element-pass.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -121,6 +121,9 @@ fn compile_pass() {

// test for https://github.com/yewstack/yew/issues/2810
::yew::html! { <div data-type="date" data-as="calender" /> };

let option_vnode = ::std::option::Option::Some(::yew::html! {});
::yew::html! { <div>{option_vnode}</div> };
}

fn main() {}
9 changes: 9 additions & 0 deletions packages/yew/src/utils/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,15 @@ impl<IN: Into<OUT>, OUT> From<IN> for NodeSeq<IN, OUT> {
}
}

impl<IN: Into<OUT>, OUT> From<Option<IN>> for NodeSeq<IN, OUT> {
fn from(val: Option<IN>) -> Self {
Self(
val.map(|s| vec![s.into()]).unwrap_or_default(),
Copy link
Copy Markdown
Contributor Author

@cecton cecton Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can actually iterate over options:

Suggested change
val.map(|s| vec![s.into()]).unwrap_or_default(),
val.into_iter().collect(),

Copy link
Copy Markdown
Member

@WorldSEnder WorldSEnder Sep 14, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this on godbolt.org, and the two versions produce different assembly, where the former is slightly smaller (llvm seems to optimize the case that val = None differently) than using collect, so I stuck with that one.

Good catch though, do you think I should add a comment explaining that?

Copy link
Copy Markdown
Contributor Author

@cecton cecton Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know 😅 my experience is more in high level languages...

Generally the rule is: if the intention is not obvious in the code, then it should be documented. So I would tend to say yes.

Long story:

Personally I wouldn't optimize that way because of my lack of experience. I just can't reason with it, I have too many questions in my mind. For example, is the code in assembly better for x86 or for WASM? Could it be different? Will that change in future releases of Rust/LLVM? I'm not asking you like they are relevant questions, I really don't know if those questions even make sense at all. I'm not even sure how to measure/evaluate which assembly code is faster (in terms of cycles or something I guess). So yeah I'm a total noob sorry xD I just can't answer for sure.

But I think that's the good part of the Rust community, we come with very different backgrounds. I prefer the readability of the iterator version but I totally agree it's more important to have fast code. The only reason for me to be against faster code is if it's very difficult to maintain (like if you would do everything unsafe (extreme scenario)). But here it's simple in both cases, the later code is more elegant which is a weak advantage compared to speed and size.

PhantomData::default(),
)
}
}

impl<IN: Into<OUT>, OUT> From<Vec<IN>> for NodeSeq<IN, OUT> {
fn from(val: Vec<IN>) -> Self {
Self(
Expand Down