Simplify function component creation

[Madoshakalaka]

Function component has a simpler syntax compared to struct components, but it still has a lot of boilerplate. The snake-case function name (as opposed to the PascalCase component name) is redundant. And it's the worse when you have a generic component, where the generic argument and the trait bound have to be repeated in three places.

Simply adding templates to IDE has its own problems. It's common to use a mix of function components both with and without property. And it's common to convert from one to another. Converting a property-less component to a property-ful component requires a lot of typing and thinking.

I want to propose a simpler and powerful function proc-macro comp! with which you can add or remove properties as you go, and which requires no code duplication at all. The syntax is:

comp!(
    CompName
    [properties]
    component body
)

Here are a few examples:

Component with no properties

before:

#[function_component(MyComponent)]
pub fn my_component() -> Html {
    html! {
        <div></div>
    }
}

after:

comp!(
    MyComponent
    html!{<div></div>}
);

Component with properties:

before:

#[derive(Properties, PartialEq)]
pub struct MyComponentProps {
    prop_a: &'static str,
    #[prop_or_default]
    prop_b: i8,
    #[prop_or(42)]
    prop_c: u8,
    #[prop_or_else(my_fn)]
    prop_d: bool,
}

#[function_component(MyComponent)]
pub fn my_component(props: &MyComponentProps) -> Html {
    html! {
        <div></div>
    }
}

after (ahhhhhh, so elegant, so much better):

comp!{
    MyComponent
    prop_a: &'static str
    prop_b: i8 or default
    prop_c: u8 or 42
    prop_d: bool or else my_fn
    html!{<div></div>}
}

Note the or, default, and else are now custom keywords. Implementation-wise, it should be possible to distinguish the component body from the props by peeking ident : type syntax, because I don't think it's valid to have this syntax in a function body.

Generic Components

before (gotta repeat <T: Clone> three times, ew):

#[derive(Properties, PartialEq)]
pub struct MyGenericCompProps<T: Clone> {
    prop_a: T
}

#[function_component(MyGenericComp)]
pub fn my_generic_comp<T: Clone>(props: &MyGenericCompProps<T: Clone>) -> Html {
    html! {
        <div></div>
    }
}

after (noice):

comp!(
    MyGenericComp<T: Clone>
    prop_a: T
    html!{<div></div>}
);

What's Implied

• MyComponentProps will be generated. It only derives PartialEq and Properties and users can't add other derives.
  I don't see this as an inconvenience because, in my experience with yew, I've never felt a need to have other derives.
  I might have missed some use cases though. I'm not against adding a custom derive syntax to the macro.

• The snake case function with the name my_component will be generated from the PascalCase component name. If properties are present, the users should understand that a props argument is injected by the macro and that they can use the props variable in the component body section of the macro.

[Madoshakalaka]

If people are happy with this, I can work out a proof of concept in a different repo. Maybe I'll call it yew-dsl @hamza1311 ;)

[ranile]

If you want, I would be happy to accept the fc_props! macro as @voidpumpkin proposed with the syntax you mentioned originally in yew-vdom-gen. I've been wanting to add props stuff to it but didn't really get the time for it. Feel free to create an issue for it and we can discuss the API more there.

[voidpumpkin]

Regarding your proposal

I am really not a fan of the proposed api as everything gets jumbled all together.
Though i really think you can create this as an separate library that provides the macro. And it does not look to hard to achieve.

Double naming issue

I think this could be solved by just overriding the function name inside the macro, though im not sure why its not done like this already

#[function_component]
pub fn MyComponent() -> Html {
    html! {
        <div></div>
    }
}

we could even go one step further and provide a optional fc shorthand like react

#[fc]
pub fn MyComponent() -> Html {
    html! {
        <div></div>
    }
}

Props and snippets

Personally i love having Props as a separate structure outside the component, but it just probably comes from me using a lot of react with typescript in the past.
I think we could think of a way to get the props inside the args

#[function_component(MyComponent)]
pub fn my_component(fc_props!{
    prop_a: &'static str,
    #[prop_or_default]
    prop_b: i8,
    #[prop_or(42)]
    prop_c: u8,
    #[prop_or_else(my_fn)]
    prop_d: bool,
}) -> Html {
    html! {
        <div></div>
    }
}

in this case even your approach works

#[function_component(MyComponent)]
pub fn my_component(fc_props!{
    prop_a: &'static str,
    prop_b: i8 or default,
    prop_c: u8 or 42,
    prop_d: bool or else my_fn,
}) -> Html {
    html! {
        <div></div>
    }
}

For generics you would need to fallback to making a separate struct

Final look

it looks like so if combining all my proposals:

#[fc]
pub fn MyComponent(fc_props!{
    prop_a: &'static str,
    prop_b: i8 or default,
    prop_c: u8 or 42,
    prop_d: bool or else my_fn,
}) -> Html {
    html! {
        <div></div>
    }
}

[ranile]

though im not sure why its not done like this already

Because function names aren't PascalCase in Rust. I was afraid it would mess up lints, though now I realize I should've tested that before making it the way it is.

we could even go one step further and provide a optional fc shorthand like react

That's just

use yew::functional::function_component as fc;

Not sure how we can help here. Maybe an alias in the prelude?

I think we could think of a way to get the props inside the args

I would prefer if props were just function arguments:

#[function_component(MyComponent)]
pub fn my_component(
    prop_a: &'static str,
    #[prop_or_default]
    prop_b: i8,
    #[prop_or(42)]
    prop_c: u8,
    #[prop_or_else(my_fn)]
    prop_d: bool,
) -> Html {
    html! {
        <div></div>
    }
}

No need to wrap it in a macro when we can avoid it. We can add a way to opt out of "props as arguments".

[voidpumpkin]

agree on all points
maybe ill open a pr soon for the fc one

[ranile]

I would like the function component be just functions. No macro or trait required.

fn FunctionComponent(props: &Props) -> Html {
    todo!()
}

This can be made possible by the following implementation:

impl<T> FunctionProvider for T
where
    T: Fn(...) -> Html
{
    /// ...
}

Of course, this would trip up lints, but that could be disabled.

[futursolo]

Unfortunately, I don't think it's possible to have raw functions as function components.

pub trait FunctionProvider {
    type TProps;
}

impl<T, P> FunctionProvider for T
where
    T: Fn(&P) -> Html,
{
    type TProps = P;
}

Gives you the following error:

error[E0207]: the type parameter `P` is not constrained by the impl trait, self type, or predicates
  --> src/main.rs:19:9
   |
19 | impl<T, P> FunctionProvider for T
   |         ^ unconstrained type parameter

Using a pure function will also lose defaulted type parameter for function components.

// not possible without procedural macros.
pub fn Link<R, Q = ()>(&props: LinkProps<R, Q>) -> Html {
    // ...
}

Moreover, You cannot have an implementation for 2 T at the same time,
so Fn() -> Html and Fn(&Props) -> Html cannot be marked as function components at the same time.

impl<T> FunctionProvider for T
where
    T: Fn() -> Html,
{
    type TProps = ();
}

impl<T, P> FunctionProvider for T // conflict implementation
where
    T: Fn(&P) -> Html,
{
    type TProps = P;
}