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

Support validating parameter properties #350

Closed
raffomania opened this issue May 1, 2019 · 8 comments
Closed

Support validating parameter properties #350

raffomania opened this issue May 1, 2019 · 8 comments
Labels
status: wontfix type: feature Issues related to new features.

Comments

@raffomania
Copy link

When using the --strictPropertyInitialization flag, I often assign properties in a classes constructor:

class User {
  @IsEmail()
  email: string;

  constructor(email: string) {
    this.email = email;
  }
}

To avoid repetition, I like to use parameter properties:

class User {
  constructor(
    public email: string
  ) { }
}

however, class-validator doesn't seem to support annotating these parameters. I would like to use them like this:

class User {
  constructor(
    @IsEmail
    public email: string
  ) { }
}
@npwork
Copy link

npwork commented Jan 5, 2021

+1 Really useful feature!!!

@NoNameProvided
Copy link
Member

You can use the definite assignment assertion (!) to tell Typescript it will be assigned later.

class User {
  @IsEmail()
  email!: string;
}

The above code will compile successfully with --strictPropertyInitialization option enabled.

@raffomania
Copy link
Author

that's cool, but in my case I actually need the constructor for other places where class-validator is not used. This forces me to add an extra line for every property to get that constructor.

@NoNameProvided
Copy link
Member

I don't understand what do you mean.

This forces me to add an extra line for every property to get that constructor.

Your example needs extra line, in mine the constructor can be omitted as it's empty.

@raffomania
Copy link
Author

raffomania commented Jan 24, 2021

I mean that I have to include the extra line in cases where I need a constructor. I need a constructor when initializing my object in unit tests, for example.
So if I already need to write the constructor, it would be nice to be able to omit the property declaration and only include the constructor.
Additionally, using definite assignment assertion makes my code less safe :(
Of course, I can understand that this is not a necessary feature and don't expect you to put time into it :)

edit: to clarify further:
your example:

class User {
  @IsEmail()
  email!: string;
}

Now say that I really, really need a constructor. I'd modify your example like this

class User {
  @IsEmail()
  email!: string;

  constructor(email) {
    this.email = email;
  }
}

But wouldn't it be nice to make this shorter?

class User {
  constructor(
    @IsEmail
    public email: string
  ) { }
}

@NoNameProvided
Copy link
Member

It's an entirely different scenario to validate constructor properties during class creation than validating existing classes. This library won't support that format because we have class-transformer for class creation. So this library will always check the properties of existing class instances.

@raffomania
Copy link
Author

I'm perfectly happy validating existing classes, there's nothing that needs to happen during class creation. I just want to put the decorators from class-validator in a different spot.

The normal decorators class-validator uses are "property decorators". I would like to have support for parameter decorators. These should automatically work with constructors.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: wontfix type: feature Issues related to new features.
Development

No branches or pull requests

3 participants