Odd behvaiour with $setViewValue + $render when debounce/async validation is used

[jsdw]

In brief, setting the value of an input field X using $setViewValue("somevalue") and then running $render() when X uses debounce or an async validator, only updates the actual visible value of X if it is presently in a valid state. If it begins (or turns into) an invalid state, the actual visible value is blanked out on the next call to $setViewValue+$render, rather than set to what was passed to $setViewValue..

A plunkr demonstrating this is here (the first input will set the second one on blur, and in the top case the second one has a 1 sec async validation attached so you'll see a model update 1 second after the blur, but not a view update. If you remove the async validator it works as expected):

http://plnkr.co/edit/h1hvf79W8ovqAlNLpBvS

And my stackoverflow question here (incase it has any more useful details):

http://stackoverflow.com/questions/26035871/angularjs-how-to-set-one-input-value-from-another-and-have-it-go-through-valida

I feel as if this is a bug rather than something I am doing wrong (though am happy to be corrected!).

I am using angular 1.3.0rc2

[shahata]

Sorry, but I might not really understand what you are trying to do. $setViewValue and $render are methods that should be used when developing custom input controls in order to report and render view value updates respectively. It does not appear you need to use those methods in your case and everything seems to behave as expected.

Here's an updated plunker that (I think) does what you mean to do: http://plnkr.co/edit/iOH6GlNwEsmjjjaQYF5n?p=preview

[jsdw]

Hello,

Thanks for your reply!

Perhaps I'm being pedantic, but the reason I wanted to use my approach was that normally when using ng-model + validation, a failed validation sets the model value to undefined. If I set the model value of some input directly as suggested (the obvious approach), it is not then changed to undefined should validation fail.

For me, this led to inconsistency in my app, as fields set by the user were made undefined when invalid, but a field set from another field by simply changing its model value was not.

In any case, I felt it odd that using $setViewValue and $render as shown in my plunkr lead to the value not being displayed on the view in certain cases as described above; this does not feel like intended behaviour so I thought I'd point it out incase that assumption was correct :)

[caitp]

normally when using ng-model + validation, a failed validation sets the model value to undefined. If I set the model value of some input directly as suggested (the obvious approach), it is not then changed to undefined should validation fail.

you can now opt out of this

[jsdw]

Ah thats brilliant, yes so it looks like if I pass "alowInvalid" to ngModelOptions it'll set the model to the value regardless, rather than to undefined. It also appears as if one can use ngModelOptions at form-level to inherit to all inputs below, Taken together I can work with inputs in a consistent way (yay!).

The main issue then is just that $setViewValue+$render does not properly display the value in some cases (I think if the form was invalid before it was called, and an async process (valdiator/debounce) is used, as in my plunkr), which feels to me like more of an actual bug than a confusion :)

[caitp]

HTML5 constraint validation causes some problems here in modern browsers, which unfortunately we are not able to circumvent, whether we want to or not (basically, programmatically setting a form control's value to a bad input will just result in clearing the control, and there isn't really any way for us to fix that :()

[jsdw]

Interesting! I don't seem to have an issue programmatically setting an input to a bad value (e.g http://plnkr.co/edit/o736LMK6aLICTjeDO4JZ) using only HTML5 bits myself (using chrome, anyway), and I can't see anything in the constraint validation API that causes inputs to be cleared, though I expect your explanation has been simplified for me and I know little about the internals of angular in this regard :) Anyhoo, thanks for the updates and the usable solution for my particular case!

[caitp]

if you set a type=number or type=date (or similar date controls) with an invalid value, you will not see the result. email and url types are different, they don't suffer from bad input, they get a type mismatch error instead.

However, angular does treat email type mismatches as bad URLs/emails and sets them to undefined (unless you opt out of undefining bad values)

[jsdw]

Aah, thanks for that! I had a play and can see what you mean now (though not quite clear how it relates to me example as I didn't think I used any validation that would lead to that?). I am getting the feeling that my confusion is/was to do with a combination of things interacting and my general lack of understanding about how they all work.

allowInvalid for instance (seems like a sensible default to me) prevents both the model and view value from being cleared (I had assumed it was only to do with the model value); having it turned on seems basically equivalent to setting the model value in my tests, which makes things work consistently. Without it turned on, setting the model value directly doesn't clear the view value, but setting through $setViewValue does.

Thanks for all your feedback, it's been extremely useful :)

[Narretz]

The actual reason why the first exampe doesn't work is because when you have debounce options, the viewValue is not commited immediately, even if you call $setViewValue(). You have to call $commitViewValue() after it in this case. But good to hear you could solve your problem.

[kristydickinson]

jsdw, thank you so much for bringing this up. Your comments and attention to this issue saved me from going insane today.