Closed narcodico closed 11 months ago
I would recommend just overriding toString
in the classes where you want to customize this behavior as it's fairly straightforward and ends up being easier to understand imo.
By that logic you should remove stringify
getters and EquatableConfig.stringify
and allow users to manually override toString
, cause why do things halfway?
Right now for consistency people need to remember that your library is overriding toString
using a specific format $runtimeType(prop1, prop2, ...)
.
@override
List<Object?> get stringifyProps => [prop1, prop2];
vs
@override
String toString() => 'ClassName($prop1, $prop2)';
Pretty obvious which one is easier to use and scales better.
@felangel
I believe it is more convenient to modify an array than a string in toString()
override and this pattern matches with get props
so I think this can get a consideration, WDYT?
Is your feature request related to a problem? Please describe. Currently there's no way to easily specify a sub-set of props you want stringified.
Describe the solution you'd like Would be useful to have another getter similar to
props
, which would allow to override the props you want stringified.Describe alternatives you've considered Manually overriding
toString
.