Merging yew-autoprops into yew

[cecton]

In function component world, this is done with yew-autoprops. It could become a part of Yew and a missing & would call for having an ImplicitClone on the prop.

Originally posted by @kirillsemyonkin in yewstack/implicit-clone#39 (comment)

I think @kirillsemyonkin is right about yew-autoprops. Defining the props directly into the declaration of the function is a huge time saver. In my opinion, this is literally "function component 2.0".

If everybody agrees I would like to make a port of yew-autoprops into yew in a way that will be backward compatible with the current function component.

Option 1

use yew::prelude::*;

#[function_component]
#[autoprops(CoolProps)] // optional argument to allow the user to specify the name of the properties struct
fn CoolComponent(#[prop_or_default] test: &i8, smth: &usize) -> Html {
    println!("test: {}", test);

    html! {
        <div>
            <p>{ smth }</p>
        </div>
    }
}

Option 2

use yew::prelude::*;

#[function_component2(properties = CoolProps)] // optional argument to allow the user to specify the name of the properties struct
fn CoolComponent(#[prop_or_default] test: &i8, smth: &usize) -> Html {
    println!("test: {}", test);

    html! {
        <div>
            <p>{ smth }</p>
        </div>
    }
}

cc @hamza1311 @futursolo @valyagolev

[futursolo]

Since we cannot rule out #[derive(Properties)] as that is more versatile when it comes to complex cases, we need to provide both options, which is going to be more work to maintain.

I do not see a significant advantage that the current third-party solution cannot provide and we need an integration into Yew.
It can provide the same experience in its current form. I am fine with it remaining status quo.

I think the idea is similar as styling solution brainstorm (#2003). I think most options proposed there didn't provide a significant advantage that requires a first-party integration where a third-party solution cannot provide, so I am fine with it being a third-party solution.

This may not be a popular opinion, however, I think it is better for yew (the crate) to have only the essential functionality, so we can work towards 1.0 by focusing on polishing what's currently existing in the crate. We may even need to move functionality to other crates (such as: send_stream) from it if we cannot stablise certain features and decided to release Yew 1.0 with a MVP approach.