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
#[derive] is not perfect (funnily enough, I wrote this before I found the Rust blog quotation, where they mention it being "Perfect derive"), and Rust generates impls with that derived trait also present for generic parameters (e.g. derive(Clone) does impl<T: Clone> Clone for ...). This would happen even for instances when the requirement for the generic parameter is not required (e.g. an Rc<T> field means the struct does not actually require Clone on T).
yew-autoprops does #[derive(PartialEq)], which means when generating impls Rust will place such a requirement on the generic parameters as well. This means following example will not be valid:
can't compare `T` with `T`
no implementation for `T == T`- required for `ExampleProps<T>` to implement `PartialEq`- required by a bound in `Properties`- consider further restricting type parameter `T`: `, T: std::cmp::PartialEq`
As all props fields are probably expected to be PartialEq (which isn't always the case with derive), I suggest manually implementing PartialEq for the props struct, containing comparisons for all the fields:
impl<T>PartialEqforExampleProps<T>{fneq(&self,other:&Self) -> bool{
#pats_modified_1 = self;// adds _1 to each field, you also have to check that no name ends with _1/_2, otherwise add more underscores i guess
#pats_modified_2 = other;// adds _2 to each field
#comparisons // prop_1 == prop_2 && another_prop_1 == another_prop_2 && ...}}
For generic parameters that are to be used directly as a type of a prop field, the user will have to declare them as PartialEq, which is the case for both derive and manual impl solutions.
This is a breaking problem (you cannot implement a custom PartialEq, unlike with non-autoprops props), and fixing it would improve experience of using generics by a lot compared to non-autoprops components.
The text was updated successfully, but these errors were encountered:
#[derive]
is not perfect (funnily enough, I wrote this before I found the Rust blog quotation, where they mention it being "Perfect derive"), and Rust generatesimpl
s with that derived trait also present for generic parameters (e.g.derive(Clone)
doesimpl<T: Clone> Clone for ...
). This would happen even for instances when the requirement for the generic parameter is not required (e.g. anRc<T>
field means the struct does not actually requireClone
onT
).yew-autoprops does
#[derive(PartialEq)]
, which means when generatingimpl
s Rust will place such a requirement on the generic parameters as well. This means following example will not be valid:As it comes up with the following error:
As all props fields are probably expected to be
PartialEq
(which isn't always the case withderive
), I suggest manually implementingPartialEq
for the props struct, containing comparisons for all the fields:For generic parameters that are to be used directly as a type of a prop field, the user will have to declare them as
PartialEq
, which is the case for bothderive
and manualimpl
solutions.This is a breaking problem (you cannot implement a custom
PartialEq
, unlike with non-autoprops props), and fixing it would improve experience of using generics by a lot compared to non-autoprops components.The text was updated successfully, but these errors were encountered: