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
I have looked at the examples provided that may showcase my question here?
Package version eg. v9, v10:
v10
Issue, Question or Enhancement:
I encountered an issue when using the eqfield validator in the DTO struct. The eqfield parameter points to a field, but in the case of a validation error, it returns a string instead of a reflection type or a separate paramField. This makes it difficult to determine which field caused the error and to access its JSON tag.
I been thinking about doing that for a long time, the only issue is not knowing which reflection value field to return sometimes and how to represent nested validations. Interesting in hearing everyone's thoughts though.
The above example is very straight forward and so seems easy but take the following sudo code example:
keys,required,endkeys - seems to still apply to MapOrKeyToB for struct C level validations, but the field is actually the key of the map field so which should we return?
endkeys,required,otherstructvalidation - seems to apply to MapOrKeyToB for struct B level validations, but the value is the map value of the map field so which should we return?
C & B structs Value fields seem to apply to their own struct fields
Unknowns are:
If struct A or B's Value fields fail how would we know the reflection field value is nested? the reflection value has no reference or lineage information.
Should we return StructField for MapOrKeyToB, struct C or struct B which don't have a StructField in the map example? What about other types also C or B could be a string, int etc... and not a structure either.
This library also validates individual fields not attached to struct and so no StructField may exists at all.
Happy to discuss further, I don't know how I would consolidate/reconcile all into working consistently across like field name using dot notation does eg. B[C].Value can.
One idea that might help is to introduce a ParamField or ParamStruct feature. This would let developers choose what they want to get when there’s a validation error. For example, with the eqfield validator, developers could decide to receive either the specific field that caused the error (ParamField) or the whole struct that contains that field (ParamStruct), especially when they know that the field is part of a nested structure rather than a primitive type.
Package version eg. v9, v10:
v10
Issue, Question or Enhancement:
I encountered an issue when using the
eqfield
validator in theDTO
struct. Theeqfield
parameter points to a field, but in the case of a validation error, it returns a string instead of a reflection type or a separateparamField
. This makes it difficult to determine which field caused the error and to access its JSON tag.Code sample, to showcase or reproduce:
I'm using
en.RegisterDefaultTranslations
The text was updated successfully, but these errors were encountered: