angular: Angular's input validation should align with HTML5 validation! (Currently it does not!)
I’m submitting a … (check one with “x”)
[x] bug report
[x] feature request
[ ] support request
Current behavior
Suppose we have such an input:
<input #nativeControl #ngControl="ngModel" type="number" min="30">
Now if we enter 25 in that box, the ngControl.valid property will be true, while nativeControl.validity.valid will be false and nativeControl.validity.rangeUnderflow will be true.
Moreover, if we enter invalid characters (e.g. only dashes) in such a field, ngControl.valid property will be true. At the same time, nativeControl.validity.valid will be false and nativeControl.validity.badInput will be true;
Another example: <input type="email"> is not validated by Angular (i.e. is always valid), while HTML5 validation correctly sets ValidityState.typeMismatch to true (and ValidityState.valid to false) if invalid email address is entered.
Currently I’m testing this with chrome but I don’t think there will be any differences with other browsers. They all implement HTML5 validation pretty much without any issues.
Expected behavior
I think HTML5 standard already implements validation mechanism pretty well. Please view https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5/Constraint_validation and https://developer.mozilla.org/en-US/docs/Web/API/ValidityState for example. I think Angular should either emulate, or even directly depend on that mechanism (ValidityState values defined by HTML5).
Yes I know one can implement custom validator in angular and basically emulate anything, but… I think I’d rather have <input type="email"> validation out of the box, rather than to reinvent the wheel and write new validator just for email checking.
[EDIT] Minimal reproduction of the problem with instructions Please view an example: http://plnkr.co/edit/5pzh5pV2ExF3vKGhgEtq?p=info
Just enter number in first input, or email in second input, and you will see that Angular’s validator does not respect min attribute (of <input type="number">) and also <input type="email"> inputs.
- Angular version: 4.0.X
- Browser: [all]
- Language: [TypeScript 2.X]
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 63
- Comments: 40 (6 by maintainers)
Links to this issue
Commits related to this issue
- feat(forms): introduce min and max validators This commit adds the missing `min` and `max` validators. BREAKING CHANGE: Previously `min` and `max` attributes defined on the `<input type="number">` ... — committed to sonukapoor/angular by sonukapoor 4 years ago
- feat(forms): introduce min and max validators This commit adds the missing `min` and `max` validators. BREAKING CHANGE: Previously `min` and `max` attributes defined on the `<input type="number">` ... — committed to sonukapoor/angular by sonukapoor 4 years ago
- feat(forms): introduce min and max validators This commit adds the missing `min` and `max` validators. BREAKING CHANGE: Previously `min` and `max` attributes defined on the `<input type="number">` ... — committed to sonukapoor/angular by sonukapoor 4 years ago
- feat(forms): introduce min and max validators This commit adds the missing `min` and `max` validators. BREAKING CHANGE: Previously `min` and `max` attributes defined on the `<input type="number">` ... — committed to sonukapoor/angular by sonukapoor 4 years ago
- feat(forms): introduce min and max validators This commit adds the missing `min` and `max` validators. BREAKING CHANGE: Previously `min` and `max` attributes defined on the `<input type="number">` ... — committed to sonukapoor/angular by sonukapoor 4 years ago
- feat(forms): introduce min and max validators This commit adds the missing `min` and `max` validators. BREAKING CHANGE: Previously `min` and `max` attributes defined on the `<input type="number">` ... — committed to sonukapoor/angular by sonukapoor 4 years ago
I’ve tried reading over #17491 and I’m still not sure what the actual resolution of this problem is supposed to be. If I have an
<input type="number" min="0" [(ngModel)]="val" #num="NgModel">, I should be able to assume thatnum.validwill befalsewhen the input’s value is-10. That’s just a really basic and logical assumption that developers will make, and to do otherwise, out of the box, without requiring an extra “workaround” directive, etc, is a disservice to them.Does anybody here disagree? Is there a path forward to making this Just Work? If not, is there a well-publicized documented workaround that adds only minimal burden on developers?
How come this is a type of
featurewhen it should be aBUG!!This should be implemented. How come this is still not a thing in v7.0?
1+
Documentation literally states that template driven forms should match the attributes with native html validation. This is real deceptive.
Hard to imagine Angular still does not provide a min max directive validator out of the box. Kind of a joke, to be honest.
Still nothing in 2020. A bit ridiculous.
The Validators documentation is deceptive and should be updated. It lists validators only available to reactive forms. Nowhere does it mention that only a select few of the validators listed can be used on a template form.
As of Angular 8.x.x, min and max are still not supported in template forms.
+1 Reactive forms are too much for a component that has just a single
input type=numberIMHO,minandmaxvalidations could be supported out-of-the-box in a template-driven approach.I can’t believe this is not implemented yet for template-driven forms. I was migrating a component from AngularJS that used ng-min/ng-max just fine, and I find that there is no equivalent in Angular.
For other people coming here:
(keyup). This is the one I ended up doing as a reactive form is overkill for simple cases.#26787 was locked by the bot, let’s not allow that to happen here. Still current, still relevant.
Hi, just a quick update: there is a PR #39063 (in progress), which implements min/max validators for
<input type="number">. These validators should be available in the next major version of Angular (most likely v12).Almost 4 years later, thank you!!
Any updates on this?
Any update pleaseeeeeeeeeeeeeeeee
Sounds like people want to use their own min\max directives in their components that implement ControlValueAccessor. I think that is a valid request and that template driven form directives for min\max should really only apply to input fields and not any other component. It seems as though the original implementation used the following selector:
[min][formControlName],[min][formControl],[min][ngModel]@Maximaximum mentioned that this should be this selector instead:
[formControlName],input[type=number][min][formControl],input[type=number][min][ngModel]I think this is the ideal solution to not interfere with custom components while still providing the default assumption that html5 validation can be used with input fields out of the box.
Expected ‘min’ to work for input type=“number”.
At the very least there should be a documentation update in the meantime, as @dscalzi mentioned, it is deceptive. If there is time to close duplicate issues on github (6 so far) surely there is time to update docs?
@zoechi Please view the Plunker at: http://plnkr.co/edit/5pzh5pV2ExF3vKGhgEtq?p=info Just enter number in first input, or email in second input, and you will see that Angular’s validator does not respect min attribute (of
<input type="number">) and also<input type="email">inputs.@buu700 Unfortunately it is not relevant in this case.
I tried to address min/max validation separately (following @trotyl 's comment) but that issue was closed as a duplicate. If that means we want to stick with this approach and use the existing
min/maxattributes then it seems there are some approaches that don’t need to create a breaking change.For example, an additional module could be created (
HtmlValidationModuleor something) which adds the directives. Existing code would not be affected but anyone that wanted to usemin/maxcould easily add support for it.Alternatively,
minandmaxdirectives could be added by default with a flag to turn them off. This would be a breaking change but anyone significantly affected could easily fall back to the default behavior.@SilvioAmaral Make sure to read about forks. You should create one, than push your branch to your forked repo and than create a PR following this guide.
The answer I got on #15531 might possibly fix your problem.