New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binding doesn't work with input type="email" #1426

Closed
Shedal opened this Issue Sep 27, 2012 · 3 comments

Comments

Projects
None yet
4 participants
@Shedal

Shedal commented Sep 27, 2012

See example:
http://jsfiddle.net/Shedal/MLsMG/14/

Try entering a value into the emailInput field. The {{emailInput}} placeholder does not get updated.
The $watch callback in the controller only gets called when the value changes from/to blank string. Also, the newValue parameter's value is incorrect (undefined for non-blank emailInput values - see console log).

If you try to change input type to text, everything works as expected.

Tested with AngularJS 1.0.2 in latest Chrome and Firefox on Mac OS X Lion.

@pkozlowski-opensource

This comment has been minimized.

Show comment
Hide comment
@pkozlowski-opensource

pkozlowski-opensource Sep 27, 2012

Member

@Shedal AngularJS will bind to a model only when a value in the input field passes validation. As soon as you supply a valid e-mail adress model is bound, watchers are updated etc. This is how angular works atm.

Member

pkozlowski-opensource commented Sep 27, 2012

@Shedal AngularJS will bind to a model only when a value in the input field passes validation. As soon as you supply a valid e-mail adress model is bound, watchers are updated etc. This is how angular works atm.

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Dec 12, 2012

Member

Having played around with Angular forms for some time now, I am not convinced that the model that is bound to the input controls should "really" be the truth. There are use cases where you have inputs that are not entirely valid but are good enough to be kept.

A simple example would be writing an email. Imagine I am writing an email to some one. I write down their email address but it is not quite correct - in fact it is not a valid email address at all. I decide to save a draft copy and come back to the address issue later. Right now, an AngularJS form would not allow us to save the "incorrect" email address in the draft email since the email is not valid.

I believe that what we ought to do is decouple "$parsers and $formatters" from "$validators". The idea being that the former can make changes to the values as they pass between the model and the view, while the latter can set whether we consider the value valid or not. The model will still be updated even if the view is invalid but the ngModelController will know it is not valid.

We also have to do this anyway if our validator is asynchronous, since we have to return "some" value while we wait for the asynchronous validation to occur.

One thing that we are doing in our apps any way, is to store a copy of the "original" model so that we can "reset" the form. This is a very nice pattern and allows us to also do neat things, like disable the save button if what is in the form is no different to what was there originally - this is subtly different to being $pristine, since the user could change something and then back again with the form no longer $pristine.

@mhevery What do you think?

Member

petebacondarwin commented Dec 12, 2012

Having played around with Angular forms for some time now, I am not convinced that the model that is bound to the input controls should "really" be the truth. There are use cases where you have inputs that are not entirely valid but are good enough to be kept.

A simple example would be writing an email. Imagine I am writing an email to some one. I write down their email address but it is not quite correct - in fact it is not a valid email address at all. I decide to save a draft copy and come back to the address issue later. Right now, an AngularJS form would not allow us to save the "incorrect" email address in the draft email since the email is not valid.

I believe that what we ought to do is decouple "$parsers and $formatters" from "$validators". The idea being that the former can make changes to the values as they pass between the model and the view, while the latter can set whether we consider the value valid or not. The model will still be updated even if the view is invalid but the ngModelController will know it is not valid.

We also have to do this anyway if our validator is asynchronous, since we have to return "some" value while we wait for the asynchronous validation to occur.

One thing that we are doing in our apps any way, is to store a copy of the "original" model so that we can "reset" the form. This is a very nice pattern and allows us to also do neat things, like disable the save button if what is in the form is no different to what was there originally - this is subtly different to being $pristine, since the user could change something and then back again with the form no longer $pristine.

@mhevery What do you think?

@sese

This comment has been minimized.

Show comment
Hide comment
@sese

sese Dec 12, 2012

I can understand the validation when is coming from view, but not from model, because as I shown in example ( http://jsfiddle.net/nnsese/uptnx/10/), the issue is in model and I have to fix that and also set the form as invalid. I write my own validation and allow the value when is passing the $formatters, but I kept the behavior when is coming from $parsers

http://jsfiddle.net/nnsese/xJqpC/6/

In my particular case I'm happy with this solution, I don't know if this should be right the behavior.

sese commented Dec 12, 2012

I can understand the validation when is coming from view, but not from model, because as I shown in example ( http://jsfiddle.net/nnsese/uptnx/10/), the issue is in model and I have to fix that and also set the form as invalid. I write my own validation and allow the value when is passing the $formatters, but I kept the behavior when is coming from $parsers

http://jsfiddle.net/nnsese/xJqpC/6/

In my particular case I'm happy with this solution, I don't know if this should be right the behavior.

cullen-tsering referenced this issue in cullen-tsering/angular.js Aug 11, 2016

docs(guide/Forms): describe your change...
angular data binding fails when input type is "email", switching to "text" makes the sample work
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment