String does not implement Properties

[LucaCappelletti94]

At this time, it appears that the Properties trait is not implemented for several std types, such as String:

the trait bound `std::string::String: yew::Properties` is not satisfied the following other types implement trait `yew::Properties`

It would be quite handy to have it, as in several instances I have simple component which receive a single attribute as input, such as the following one:

//! HTML rendering of an OAuth login provider object.
use yew::prelude::*;

#[function_component(FAIcon)]
/// Renders a Font Awesome icon.
pub fn fa_icon(icon: &String) -> Html {
    html! {
        <i class={format!("fa-solid fa-{}", icon)} aria-hidden="true"></i>
    }
}

I will try to make a PR adding this - I am unsure whether there are strong reasons for this type not being supported.

[WorldSEnder]

Properties is meant to be a struct with a field for every property your component can receive. In your case, this is a single property. You would still need to add a small struct describing this.

#[derive(PartialEq, Properties,)]
pub struct FaIconProps {
    icon: String,
}
/// Renders a Font Awesome icon.
#[function_component]
pub fn FAIcon(FaIconProps { icon }: &FaIconProps) -> Html {
//            ^------------------^ note that we can pattern match the struct away in the argument
    html! {
        <i class={format!("fa-solid fa-{}", icon)} aria-hidden="true"></i>
    }
}
// Later
<FAIcon icon="web-awesome" />

In case you don't want or need to write the struct by hand, there's yew-autoprops that generates this struct from a function signature - this seems to be what you are expecting to happen, but that's not the default.

[LucaCappelletti94]

Thank you for your reply - I do understand that I can always wrap the property in a wrapper struct and even do it automatically with the suggested yew-authoprops, but the question primarily is: why thought?

Wouldn't it be simpler to just implement Properties for the std types? I am experimenting with doing exactly that in this fork, but I haven't yet tested the code.

[Madoshakalaka]

From an ergonomics perspective, I imagine people will need to add more and more non-primitive props to the component and end up having to create a struct?

Is it possible to have multiple props like this?

#[derive(Properties, PartialEq)]
struct TitileExtraProps{
// ...
}

#[function_component]
fn Title(title: &String, extra_props: &TitileExtraProps) -> Html {
    html! { <h1>{ title }</h1> }
}

I wonder if it's a good idea to make function_component work like autoprops when there are multiple parameters.

[LucaCappelletti94]

While I agree it may be a valid solution, it would break API compatibility when the number of arguments is 1

[WorldSEnder]

#[function_component(props(auto))] or something similar seems reasonable to keep api compatbility though in this case, I'd prefer #[function_component(props(generate))] since "auto" doesn't really tell me anything unless I already know of yew-autoprops.

[LucaCappelletti94]

Yes, and it is not unthinkable that other things to automatically generate may be added in the future.