Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding a new function to return reflection type #1357

Open
2 tasks done
K1ender opened this issue Jan 4, 2025 · 2 comments
Open
2 tasks done

Consider adding a new function to return reflection type #1357

K1ender opened this issue Jan 4, 2025 · 2 comments

Comments

@K1ender
Copy link

K1ender commented Jan 4, 2025

  • I have looked at the documentation here first?
  • 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.

Code sample, to showcase or reproduce:

var _validator = validator.New()

type DTO struct {
	Password        *string `json:"password" validate:"required,min=8"`
	PasswordConfirm *string `json:"password_confirm" validate:"required,eqfield=Password"`
}

func main() {
	password := "passwordpassword"
	password_confirm := "password_confirm"
	data := DTO{
		Password:        &password,
		PasswordConfirm: &password_confirm,
	}
	err := _validator.Struct(data)

	if err != nil {
		for _, err := range err.(validator.ValidationErrors) {
			fmt.Println(err.Param())
		}
	}
}
"password_confirm": [
        "password_confirm must be equal to Password"
]

I'm using en.RegisterDefaultTranslations

@deankarn
Copy link
Contributor

deankarn commented Jan 4, 2025

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:

struct C {
     Value string `validate:"required,..."`
}
struct B {
   Value string `validate:"required,..."`
}
struct A {
    ...
   MapOrKeyToB map[C]*B `validate:"required,dive,keys,required,endkeys,required,otherstructvalidation"`
}
  • required - seems to apply to field MapOrKeyToB
  • 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.

@K1ender
Copy link
Author

K1ender commented Jan 5, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants