Port yew-autoprops to yew-macro #3505
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
Visit the preview URL for this PR (updated for commit d9b1532): https://yew-rs--pr3505-autoprops-3i3ue3yy.web.app (expires Fri, 29 Dec 2023 07:00:41 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Benchmark - coreYew MasterPull Request |
Size Comparison
|
Benchmark - SSRYew Master
Pull Request
|
|
This is awesome, this will reduce so much boilerplate, might be one of the best, if not the best feature introduced by the next version of Yew 🔥 |
|
It will probably take a while to merge, so for the time being, consider yewstack/yew-autoprops#9 (which is also yewstack/yew-autoprops#7, but this one is not really breaking) and yewstack/yew-autoprops#8, as they are kind of breaking issues, if you have not already fixed them in your port |
i know right!!! all the credits is to @valyagolev seriously |
|
I'd rather use the function_component attribute instead of adding a new autoprops one |
|
oh yeah, smth like |
|
I just checked Dioxus, their alternative is called I recommend the following variants:
Optionally (if user wants to be more explicit, like in Python's functions and Java's annotations),
Instead of equals it can look like calls (e.g. Also remember about #3447. |
|
I, for one more, am very interested in this. Writing props structs seems tedious and redundant compared to just using the function arguments on the handler function. I would love to see this functionality available somewhere, and it does seem like something that should be a built in part of yew, but if it's a separate crate, that's fine for me too. I just want to use it, ideally sooner than later ;) |
|
My stance on this feature request:
|
|
@cecton is this something you could put up as a change on the old repo, that gets transferred to you? @futursolo is the debate over the feature in concept, or just the specific syntax chosen? The implementation seems to do the thing which is indeed desirable, or do you think this is not a desirable feature at all? To be clear, it makes sense that props do need to exist sometimes, and this autoprops feature should be purely opt-in. Do you think this is valuable given those conditions? |
| } | ||
|
|
||
| #[function_component] | ||
| fn HelloWorld(props: &Props) -> Html { | ||
| html! {<>{"Hello world"}{props.name.clone()}</>} | ||
| fn Hello(&Props { is_loading, ref name }: &Props) -> Html { |
There was a problem hiding this comment.
I'm using the syntax proposed here: yewstack/implicit-clone#39 (comment) by Alex Parrill. I think this should appear a lot more in the doc. (Please let me know your opinion on this.)
I think I learned that syntax in the context of match at the beginning I was using Rust but then I completely forgot about it and I'm not sure I have ever saw it used in destructuring like that.
Most of the time you will want to use this syntax. Actually probably always. Because it allows dereferencing the primitive types automatically (the Copy-able types). For types that are Implicit-lyCloneable like AttrValue it's actually best to take them by reference because you can pass that reference directly to the properties of child component. And it won't move it because it's a reference.
There was a problem hiding this comment.
It's certainly handy to know, but not to always use, since writing the name of the props type twice can get cumbersome really fast. If only Rust had something like anonymous struct patterns...
There was a problem hiding this comment.
YESSS I know..... well at least autoprops makes it easier in both ways (Prop struct creation + destructuring)
|
@yewstack/yew another review also here please. |
Fixes #8 Fixes #7 Fixes #9 Fixes #3 Related to yewstack/yew#3505
cecton
dismissed
futursolo’s stale review
old review, the code has been moved to yew-autoprops
This is taking too long. Since this PR is not touching anything critical, not even code, I will be merging soon |
Description
cc @kirillsemyonkin @valyagolev
Proposal for #3499
Checklist