Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

Commit

Permalink
fix(input): resolves on-focus validation checks
Browse files Browse the repository at this point in the history
  • Loading branch information
Robert Messerle committed Feb 27, 2015
1 parent da18d92 commit 2f17c8f
Showing 1 changed file with 4 additions and 8 deletions.
12 changes: 4 additions & 8 deletions src/components/input/input.js
View file
Original file line number Diff line number Diff line change
Expand Up @@ -169,8 +169,9 @@ function inputTextareaDirective($mdUtil, $window) {
setupTextarea();
}

var touched = false;
var isErrorGetter = containerCtrl.isErrorGetter || function() {
return ngModelCtrl.$invalid && ngModelCtrl.$touched;
return ngModelCtrl.$invalid && (touched || ngModelCtrl.$touched);
};
scope.$watch(isErrorGetter, containerCtrl.setInvalid);

Expand All @@ -182,14 +183,9 @@ function inputTextareaDirective($mdUtil, $window) {
if (!isReadonly) {
element
.on('focus', function(ev) {
touched = true;
containerCtrl.setFocused(true);

// Error text should not appear before user interaction with the field.
// So we need to check on focus also
//ngModelCtrl.$setTouched();
//if ( isErrorGetter() ) containerCtrl.setInvalid(true);
scope.$digest();

scope.$evalAsync();
})
.on('blur', function(ev) {
containerCtrl.setFocused(false);
Expand Down

4 comments on commit 2f17c8f

@ruant
Copy link

@ruant ruant commented on 2f17c8f Mar 2, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this commit the input get marked invalid as soon as you give focus to it.
Shouldn't we give the user a chance before telling them that the field is invalid?

@ThomasBurleson
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ruant - There are two (2) schools of thought regarding this.

What if the user is tabbing through the multiple inputs and only gets notified of an invalid input only when blurring. Now the user must reverse tab or reselect the field to update the invalid condition. This solution is very disruptive to a smart RUX and does not allow the software to proactively guide the user.

The intention here is to be proactive instead of reactive.

@gkalpak
Copy link
Member

@gkalpak gkalpak commented on 2f17c8f Mar 2, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why've struggled for so long to get this to a working state (where the error is shown when $invalid && $touched and now this changes again 😞

@ThomasBurleson, I don't think there is any school that advocates showing errors even before the user had a chance to actually interract with the field (i.e. give some input).
Showing hints about how a field should be filled (e.g. the expected format, if its required, the min/max length/value etc) is one thing and marking the field's value as invalid is another.
There are labels, placeholders, help-blocks, asterisks etc for the former and (red) error messages, error styles for the latter.

IMO, having the input show up red and having red messages appear, before I have the chance to enter anything (just because I focused a field) of having error states jump between valid/invalid as I type (*) is very distracting.

jm2c

(*): E.g. me@mail <-- valid, me@mail. <-- invalid, me@mail.c <-- valid

@gkalpak
Copy link
Member

@gkalpak gkalpak commented on 2f17c8f Mar 2, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, the docs need updating.

Please sign in to comment.