How can I return an IntoView from a match?

[superjose]

Hi everyone 🤗.

I'm currently trying to wrap implement a Typography component which will hold different variants: h1, h2, h3..., p, etc.

I wonder if this is the best way to do it. I used to do this pattern in Yew: implement a custom function to the enum to render what I'm looking for.

match arms have incompatible types
expected struct leptos::HtmlElement<H1>
found struct leptos::HtmlElement<leptos::html::P>

use leptos::*;

pub enum LeptosTypographyVariants {
    H1,
    P,
}

impl LeptosTypographyVariants {
    pub fn render(&self, cx: Scope, children: Children) -> impl IntoView {
        match self {
            LeptosTypographyVariants::H1 => view! {cx, <h1>{children(cx)}</h1>},
            LeptosTypographyVariants::P => view! {cx, <p>{children(cx)}</p>},
        }
    }
}

pub fn leptos_typography(
    cx: Scope,
    variant: LeptosTypographyVariants,
    children: Children,
) -> impl IntoView {
    variant.render(cx, children)
}

I'm also open to a better pattern if that doesn't work.

[gbj]

Check out this section of the guide: https://leptos-rs.github.io/leptos/view/06_control_flow.html?highlight=Into_any#note-type-conversions

[gbj]

Check out this section of the guide: https://leptos-rs.github.io/leptos/view/06_control_flow.html?highlight=Into_any#note-type-conversions

[superjose]

Jesus Christ this was fast!

Thanks Greg! Thanks for the awesome work so far!

[metatoaster]

That section could use an update, perhaps to include what kind of error message the compiler may generate. In leptos-0.6 The following actually does not result in a compilation error, since the outer tag is basically the same (what is returned by One or Two can be totally different, as long as they are encapsulated in the same tag across all match branches it doesn't matter):

#[component]
pub fn One(s: String) -> impl IntoView {
    view! { <span>{s}</span> }
}

#[component]
pub fn Two(s: String) -> impl IntoView {
    view! { <span>{s}</span> }
}

#[component]
pub fn Match(s: String) -> impl IntoView {
    match s.as_ref() {
        "one" => view! { <div><One s/></div> },
        "two" => view! { <div><Two s/></div> },
        _ => view! { <div></div> },
    }
}

In leptos-0.7 this trick to avoid the use of .into_any() will result in this rather confusing error message:

error[E0308]: `match` arms have incompatible types
   --> src/app.rs:111:18
    |
98  |   pub fn One(s: String) -> impl IntoView {
    |                            ------------- the expected opaque type
...
103 |   pub fn Two(s: String) -> impl IntoView {
    |                            ------------- the found opaque type
...
109 | /     match s.as_ref() {
110 | |         "one" => view! { <div><One s/></div> },
    | |                  ----------------------------- this is found to be of type `leptos::html::HtmlElement<leptos::html::Div, (), (impl leptos::IntoView,), Dom>`
111 | |         "two" => view! { <div><Two s/></div> },
    | |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found a different opaque type
112 | |         _ => view! { <div></div> },
113 | |     }
    | |_____- `match` arms have incompatible types
    |
    = note: expected struct `leptos::html::HtmlElement<_, _, (impl leptos::IntoView,), _>` (opaque type at <src/app.rs:98:26>)
               found struct `leptos::html::HtmlElement<_, _, (impl leptos::IntoView,), _>` (opaque type at <src/app.rs:103:26>)
    = note: distinct uses of `impl Trait` result in different opaque types
    = note: this error originates in the macro `view` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you could change the return type to be a boxed trait object
    |
108 | pub fn Match(s: String) -> Box<dyn IntoView> {
    |                            ~~~~~~~         +
help: if you change the return type to expect trait objects, box the returned expressions
    |
110 ~         "one" => Box::new(view! { <div><One s/></div> }),
111 ~         "two" => Box::new(view! { <div><Two s/></div> }),
    |

Using .into_any() as documented will correct this issue, as the compiler's suggestion to use Box<dyn IntoView> is definitely not useful here (not to mention the same opaque type may be a further source of confusion for Rust newbies, but thankfully if they delve into this further they will be able to find useful answers relate to this elsewhere on the web).