ngModelController.$validators pipeline and refactoring #7377
Conversation
matsko
changed the title
| ctrl.$$deferValidation = false; | ||
| var value = ctrl.$modelValue; | ||
| forEach(ctrl.$validators, function(fn, name) { | ||
| ctrl.$setValidity(name, fn(value)); |
There was a problem hiding this comment.
It seems to me that this is wrong; it seems like this says that if you have two validators, and the first one returns false, but the second one returns true, that the control will be set to valid. Am I missing something here?
There was a problem hiding this comment.
only if they're all valid will the control be valid, afaik
There was a problem hiding this comment.
each validator has a different name, so there is no problem here.
There was a problem hiding this comment.
it's an AND operation when $valid is determined.
There was a problem hiding this comment.
OK, I looked over the code for $setValidity and discovered it was keeping track of how many times the control was valid vs. invalid. My mistake.
|
What is the relationship between $validators and setting the model & view values? Are they still only set when it is valid? |
|
@Narretz validations will happen whenever the model value changes. It will always be the parsed value. The view value is ignored. |
|
A minor thing: since validations are not short-circuiting anymore, pipeline isn't a very good description. It may confuse people who are familiar with parsers / validators pipeline. |
|
@Narretz yes that is true. Maybe queue would be better. |
|
to summarize, I have these questions:
|
|
Regarding model updates when invalid: The intention is that sometimes you want the value in the model even though it is invalid (same goes for model -> view and formatters). But this could be made configurable. Updating the model also means that you don't see validation errors before the model is updated, which means consistency with the new model update options. A good example is entering an email address, and getting the 'invalid' error message while you are typing, which wouldn't happen with a debounce. However that this is unflexible, as sometimes you want immediate feedback.. @shahata has a commit here that defines validateOn options similar to the model updates: #7414, so validation errors can be displayed before model updates are made. Maybe this can be integrated - which would mean $validators use the (parsed) viewValue again |
…e the $validators pipeline Fixes angular#6304
BREAKING CHANGE:
If an expression is used on ng-pattern (such as `ng-pattern="exp"`) or on the
pattern attribute (something like on `pattern="{{ exp }}"`) and the expression
itself evaluates to a string then the validator will not parse the string as a
literal regular expression object (a value like `/abc/i`). Instead, the entire
string will be created as the regular expression to test against. This means
that any expression flags will not be placed on the RegExp object. To get around
this limitation, use a regular expression object as the value for the expression.
//before
$scope.exp = '/abc/i';
//after
$scope.exp = /abc/i;
|
MERGED |
|
Landed as 1be9bb9 |
Fixes #6750
Fixes #6304
Fixes #5164