Merge port of yew-autoprops in Yew to yew-autoprops #10
Conversation
|
Seems like its generating an unexpected comma somewhere (be it struct or fn) when there are no props but there are generic types |
|
Repro: #[autoprops]
#[function_component]
pub fn Test<T>() -> Html {
html! {}
} |
|
@kirillsemyonkin fixed |
|
I think to trigger CI you may wanted to rerun all jobs, sometimes I see that button in the actions section |
|
No I really wanted to trigger the CI with a different commit hash ^_^ |
|
TIL that you need to add the rust version in swatinem/cache key for it to work properly 🤦♀️ I have like 10 repos that are not doing that huh |
|
Here is another one |
|
Fixed |
|
|
@kirillsemyonkin fixed |
Following the advice of @kirillsemyonkin, I'm adding a function `implicit_clone()` which will enforce that the type is implementing `ImplicitClone` while still actually cloning. Related to yewstack/yew-autoprops#10 (comment)
|
@hamza1311 @kirillsemyonkin ok I think this is ready now |
|
What is the current status of this? |
| 7 | fn CantAcceptReceiver(&self, b: bool) -> Html { | ||
| | ^^^^^ | ||
|
|
||
| error: could not find #[function_component] attribute in function declaration (#[autoprops] must be placed *before* #[function_component]) |
There was a problem hiding this comment.
I think we cannot enforce a function_component macro by reading the macro name as function_component can be renamed with as and can be implemented via other macros like stylist::yew::styled_component.
There was a problem hiding this comment.
Though imo we should use a separate proc macro instead of outputting the function component from an extended macro. This allows better composition:
#[styled_component]
#[autoprops]
#[function_component]
fn MyStyledComponent() -> Html {
html! {<div class={css!("color: red;")}>{"Hello World!"}</div>}
}
There was a problem hiding this comment.
yeah #[styled] #[autoprops] #[component] / #[autoprops] #[styled] #[component] (yewstack/yew/#3447 would be a breaking change btw so stylist would need to be updated anyway) should compose well, but its up to @futursolo to make a breaking change just for that
| #[test] | ||
| fn tests_pass() { | ||
| let t = trybuild::TestCases::new(); | ||
| t.pass("tests/function_component_attr/*-pass.rs"); |
There was a problem hiding this comment.
Pass tests should also only be run with MSRV.
Rustc may introduce additional lints over the time to fail pass tests.
There was a problem hiding this comment.
Tests breaking somehow to me sounds like a good idea, despite being slightly annoying upon trying to perform an unrelated PR (already happened with clippy before). Maybe have them run under both MSRV and latest stable so we can see whether such a lint change occured?
There was a problem hiding this comment.
@kirillsemyonkin it's already what I did here
But in Yew we only run them against MSRV.
imo it's best to run it on both because we need the thing to keep working on stable and to be alerted asap when it's not.
I don't mind restricting this test to MSRV though.
There was a problem hiding this comment.
@futursolo do you agree with the argument or you still prefer the passing test to run only on MSRV?
|
@yewstack/yew can I have a final review on this? |
|
@cecton hi you are my angel, thanks for the work |
Can we skip such a review since it is more-or-less separate from Yew and proceed to merge? We can have extra merges later, independent of Yew's slow cycle |
|
Ideally anyone's work on a stylist PR for |
Yeah I think the other maintainers are a bit overbooked at the moment so let's merge it as is. Worst case scenario we open issues or fix things later on. |
Fixes #8
Fixes #7
Fixes #9
Fixes #3
Related to yewstack/yew#3505