You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assuming you want to have some common properties on a component (like id, name, …) it would be great to have some form of inheritance for properties.
To be a bit more specific, I currently have two use cases, which feel related:
a) Having an id field (plus a few others) on every component
b) Having a "base" component, which then has different variations. For example: a button, which can be a link (<a>) or an actual <button>. Both share 80% of their properties and implementation, but the rest varies. I would prefer to leverage Rusts strict type system in order prevent problems.
I read about others have the same wish, going in the direction of a flatten attribute.
I peeked a bit into the code and came up with the idea of using a single base and Deref to get there, the idea being:
Rendering out impl Deref<Target=BaseProps> for ActualProps. Doesn't look too bad, and seems to fine for working with the type. It's not flatten, as you can only have one base, but that's good enough for a good number of use cases, and doesn't introduce a new inheritance system in Rust, but uses what the language provides.
The part I am struggling with is the generated types, used for detecting "missing" properties. HasProp and friends.
Honestly, as a user of Yew, I am struggling with that too. I would prefer some "missing field" info from the Rust compiler of some weird "trait error" when missing out a property. But taking a deeper look into the macro code and what it generates, I simply don't understand "why" it's done this way.
So maybe someone could explain it to me. Or point me to some explanation. Because maybe it could be done in a more Rust-native way?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Assuming you want to have some common properties on a component (like
id
,name
, …) it would be great to have some form of inheritance for properties.To be a bit more specific, I currently have two use cases, which feel related:
a) Having an
id
field (plus a few others) on every componentb) Having a "base" component, which then has different variations. For example: a button, which can be a link (
<a>
) or an actual<button>
. Both share 80% of their properties and implementation, but the rest varies. I would prefer to leverage Rusts strict type system in order prevent problems.I read about others have the same wish, going in the direction of a
flatten
attribute.I peeked a bit into the code and came up with the idea of using a single base and
Deref
to get there, the idea being:Rendering out
impl Deref<Target=BaseProps> for ActualProps
. Doesn't look too bad, and seems to fine for working with the type. It's not flatten, as you can only have one base, but that's good enough for a good number of use cases, and doesn't introduce a new inheritance system in Rust, but uses what the language provides.The part I am struggling with is the generated types, used for detecting "missing" properties.
HasProp
and friends.Honestly, as a user of Yew, I am struggling with that too. I would prefer some "missing field" info from the Rust compiler of some weird "trait error" when missing out a property. But taking a deeper look into the macro code and what it generates, I simply don't understand "why" it's done this way.
So maybe someone could explain it to me. Or point me to some explanation. Because maybe it could be done in a more Rust-native way?
Beta Was this translation helpful? Give feedback.
All reactions