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

feature: Conditional validation inside validation options #1721

Open
soroushmadani opened this issue Aug 17, 2022 · 4 comments
Open

feature: Conditional validation inside validation options #1721

soroushmadani opened this issue Aug 17, 2022 · 4 comments
Labels
flag: needs discussion Issues which needs discussion before implementation. type: feature Issues related to new features.

Comments

@soroushmadani
Copy link

Description

Sometimes we need to validate a field based on another field in the dto.

Proposed solution

  1. it would be nice to have an option called validateIf which is a callback function with given object.
    example:
export class TestDto {
 // ...

 @IsNotEmpty()
 @IsString()
 type: string;

 @IsUUID({ validateIf: o => o.type === "something" })
 @IsEmpty({ validateIf: o => o.type === "something" })
 @IsNotEmpty({ validateIf: o => o.type !== "something" })
 albumId: string;
}
  1. the above example would do the job for me, but it would be nicer if we could group validation somehow like below:
export class TestDto {
// ...

 @ValidationGroup([IsUUID(), IsEmpty()], { validateIf: o => o.type === "something" })
 @IsNotEmpty({ validateIf: o => o.type !== "something" })
 albumId: string;
}

or:

export class TestDto {
// ...

 @ValidationGroup(o => {
   if (o.type === "something" ) {
     return [IsUUID(), IsEmpty()]
   }
   return [IsNotEmpty()]
 })
 albumId: string;
}

In general, it's really good to access current object when validating. for example I needed to set the max value of a number based on another field. I made my own decorator which works like:

 @Max((o) =>
    o.type === DiscountPlanType.Percentage ||
      ? 100
      : false, // when false is passed, this will be skipped
  )
@soroushmadani soroushmadani added flag: needs discussion Issues which needs discussion before implementation. type: feature Issues related to new features. labels Aug 17, 2022
@braaar
Copy link
Member

braaar commented Sep 1, 2022

One way to achieve what you want today is to use the existing validation groups combined with a function that, before validating, checks some property of the object to decide which groups to validate. Once you have figured that out, you can then call validate with the groups passed in the ValidatorOptions.

I'm not saying this to discard your suggestion, but this is a basis for comparison. What are the strengths and weaknesses of these approaches compared to one another? Personally I don't use groups, so I don't have a strong opinion about them.

I would suspect that with your approach it's easy for someone reading your code (either someone else or you in the future) to struggle to understand the intricacies of the logic since it would be scattered about in various decorators. Especially your last suggestion. The flexibility of this feature means that it's hard to make sure that you are programming with a consistent pattern. I am the type of person who would be reluctant to add features that, while powerful, could encourage bad practices and messy code.

@4ybakut2004
Copy link

That would be a very useful feature.

I'm currently actively migrating from Ruby On Rails to Express, and Rails implements this very conveniently - https://guides.rubyonrails.org/active_record_validations.html#using-a-symbol-with-if-and-unless.

The if condition can be specified for a specific validation, and not for the entire field. It is often necessary to have a different set of validations for a field depending on some parameters.

@braaar
Copy link
Member

braaar commented Dec 15, 2023

@kevit-kelvin-mandlik
Copy link

Can you please release this feature? I am waiting for this for so long..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flag: needs discussion Issues which needs discussion before implementation. type: feature Issues related to new features.
Development

No branches or pull requests

4 participants