feat: add `email` validator

[michael-small]

Work in progress, would this be considered for acceptance

Reasoning

• I use the reactive for email validator all the time, and I imagine it is just as popular for many other applications
• General parity with the main Angular form packages (at least reactive forms). Personally, I have always taken it for granted when I do form validation in Angular.
• Tricky pattern that people are not likely to implement themselves. The regex pattern for this validator is mind boggling, and I pulled it directly from the Angular forms package.
• Were this to be considered something that falls under the umbrella of just letting the user pass their own regex pattern with pattern, I would probably throw the exact same regex string at it every time. I have added many email validators across various apps in my experience, so in my opinion this convenience of having a premade email validator outweighs the potential redundance.

Outstanding work

• Remove the reactive form comparison used for my reference
• Parity with implementation of reactive form email validator?
  • Though this library makes its own assumptions on validation among other things, I noticed as I lifted the regex pattern that reactive forms email validator explicitly says: // don't validate empty values to allow optional controls
  • However, other validators in this library, especially pattern as a close reference, does validate against null and undefined. And for the moment, I have made this library's proposed email validator do the same.
• Tests?
  • I would be happy to write tests, but am not sure the best way to. Outstanding question/issue for clarification: https://github.com/timdeschryver/ng-signal-forms/issues/38
  • There is more manual testing and consideration that I can do, provided this feature is something there is interest in accepting

[michael-small]

Great catch, I think we should try to keep as close to possible to the Angular behavior. Feel free to update the validator to also accept empty strings.

I could do that. However, I think if this is done, then it should be done for a few other validators as well. As per that file I link from their implementation, the same "don't validate empty values to allow optional controls" is done for:

Angular's validators names

• minValidator
• maxValidator
• emailValidator
• minLengthValidator
• patternValidator

maxLengthValidator doesn't have this but it's also kind of its own thing

This library has all of these as well and it looks like the equivalents also could use updating

---

Should they all be updated?

[timdeschryver]

Great catch, I think we should try to keep as close to possible to the Angular behavior. Feel free to update the validator to also accept empty strings.

I could do that. However, I think if this is done, then it should be done for a few other validators as well. As per that file I link from their implementation, the same "don't validate empty values to allow optional controls" is done for:

Angular's validators names

• minValidator
• maxValidator
• emailValidator
• minLengthValidator
• patternValidator

maxLengthValidator doesn't have this but it's also kind of its own thing

This library has all of these as well and it looks like the equivalents also could use updating

Should they all be updated?

The ones that accept a string as value should be updated imho. This means min and max not because they receive a number and that's already being handler by checking for falsy values. Feel free to correct me if I'm missing something.

maxLength validator is missing from the list. This can also be done in a separate PR.