Repository navigation
input validation unexpected behaviour #2841
Description
Currently input validations like min, max, ngPattern ... Modify the model of the form and this create some unexpected behavior for the end users.
Imagine that you have a form that preloads some values if the validation of one of the inputs were wrong this values would never be shown. But the field would be marked as invalid. Even though the field is not required.
You can see this situation on this example:
http://jsfiddle.net/carpasse/8Q6Uu/28/
Why is the name marked as invalid if it is not required. The user is getting wrong information because if you type one character and then empty the input the field is suddenly valid.
You can see that from the start that the model and the view are not sync. and if you start typing some values in the input the bind model properties disappear until the field gets valid.
In my opinion this behavior is wrong the validation mechanism should only mark the field as invalid and never modify the model. It is the responsibility of the developer to decide what to do with the invalid fields before submitting the data. Also if you don´t show the values from the model if they are invalid you make it much more harder for the user to quickly fix the value. By removing invalid values from the model by default you make it look as if the values were never there from the beginning.
Conclusion:
In my honest opinion validations should never modify the model.
Activity
nikitiuk0 commentedon Aug 7, 2013
Fully agree with author
niallsmart commentedon Aug 14, 2013
Dupe of #3594.
The attribution of the cause of the problem in the bug report is incorrect – Angular doesn't actually modify the model, it's just that the invalid value never makes it to the input control. Either way totally agree that it's a bad default behavior.
carpasse commentedon Aug 15, 2013
@niallsmart whether the model is modified or not is something subjective and you may be right but in my opinion the model does get modified. If you have a valid input and make it invalid the model becomes undefined making the data shown in the view unsync with the data stored in the model. If the invalid values just didn´t make it to the model then we should have the last valid value on it instead of undefined.You can reproduce this behavior on the fiddle of my first comment
Either way thanks (and also thanks to @DemonShi ) for taking the time to go through this issue
niallsmart commentedon Aug 15, 2013
@carpasse yes, the model is modified when the user starts to type in the input field. Also, the parser will prevent invalid values from being assigned to the model (by converting them to
undefined). That actually seems like the right behavior to me. That said I'm totally in agreement with you that the formatter behavior (which prevents the invalid value from being displayed to the user in the first place) is a bug.jbdeboer commentedon Sep 1, 2013
@niallsmart had a good suggestion for a fix in #3594. The next step here is to send a PR so we can discuss code design.
santialbo commentedon Sep 25, 2013
I agree with this.
Moreover when using pure html attributes like type="email" I just want to rely on the browser's validation capabilities. If I wanted additional angular-ish validation I would use ng-pattern for example.
eugeneos commentedon Dec 26, 2013
Agree. I am specifically running into the issue described in #3594 with 'input type="email"'. I have a scenario where a user logs in with their username, which is typically (but not always) an email address. I would like to use 'input type="email"' as a hint to browsers on mobile devices to display the "email virtual keyboard" (with the @ symbol, etc), and I can use "novalidate" to turn off browser validation. However, users with non-email usernames cannot log in since username ends up being undefined in my model. Obviously there's any number of workarounds I could use here, but I find it strange that Angular forces this validation step without any way to turn it off and prevents me from binding my model to the raw value that the user has entered.
jeanmartin commentedon Mar 22, 2014
+1
robdmoore commentedon Mar 24, 2014
+1
albinpoignot commentedon Apr 14, 2014
+1
caitp commentedon Apr 14, 2014
@eugeneos that does sound (to me) like a pretty valid concern. Would you have time to hack together a patch to fix this? I can't promise it would land, but I think disabling validation would be useful in some cases. If you have time, (or someone else), please put together a PR to fix this so that we can review it and consider merging it.
edit there are some pending changes to the whole "form" structure that we've got right now, which are already present in angular.dart, and I guess we need to figure out if we're bringing them into 1.3 or 2.0, so we'll talk about that a bit today. This should definitely be much easier to accomplish once the form components are restructured so that validation and value transformation are decoupled.
Narretz commentedon Jul 4, 2014
This is partially fixed in master.
Optional fields that fail something like min-length are no longer marked as invalid when the value is prefilled from the scope.
However, the model is still set to empty, so there should be an option to set invalid values on the model
mbenford commentedon Jul 6, 2014
For what it's worth, I needed a way to force data binding to take place regardless of data validity, and came up with this simple helper directive. Code here and demo here.
Narretz commentedon Jul 7, 2014
@mbenford This won't work with the $validators collection in 1.3, as they run after the $parsers, so we still need a better fix.
tbosch commentedon Aug 4, 2014
This is fixed in 1.3.x, but not yet in 1.2.x, see http://jsfiddle.net/8Q6Uu/29/
Narretz commentedon Sep 9, 2014
Invalid model -> view is fixed for most input types, except Invalid number and invalid date, which currently fail. This can't be fixed easily because browsers that support native validation will never show invalid values set with .val(), which leads to inconsistent $viewValue - input relations. I've opened a issue about this here: #8949
The other issue where invalid $modelValues are never set on scope is tracked here: #8290 with WIP here #8313
I don't think we can fix this in 1.2.x, because it relies too much on $validators. Can we close this then @tbosch?
tbosch commentedon Sep 9, 2014
@Narretz yes, agree. Thanks for analyzing!