ngModel changes model in 1.3 without any input from user, 1.2 is ok

[frfancha]

Simple plunker to illustrate:
http://plnkr.co/edit/pbL86XRPluAjUkha10Dg
Scenario is:
-set model to 3 (number 3, not string "3")
-have a maxLength on field
-add a parser to parse string from input to number
This scenario happens in no particular order (at least for me) as everything comes by binding to scope.
With angular 1.2.26 every is fine, 3 stays 3 while nobody touches the input field.
With angular 1.3.1, angular changes the model to "3" instead of 3 before the parser string to object is set, without anybody "touching" the input field.
The plunker only illustrates this behavior, the corruption of the model.
In our real life problem, when we set the parser we also set a formatter model to view, and this formatter fails with angular 1.3 because it finds "3" instead of the original 3.
With angular 1.2 everything works fine.

[lgalfaso]

Hi, if you want numbers, why not add type="number" ?

[caitp]

This is a duplicate of a few different issues --- so, I know we are translating the view value, but I honestly don't know where we're translating the model value, it's just bizarre.

In the mean time, merging this with the original issues

[frfancha]

Edit: this is an answer to Igalfaso, sorry forget to mention that.
Because all these fields have formatter/parser set from DB settings + user preferences, these arrive together with the data to manage display.
E.g. 0.5 is displayed as (and parsed from) 50,00% for French user with db saying this is a percentage field.
This was working very well in 1.2 , the goal is to replace all our data entry applications.

[caitp]

Actually, I guess it's slightly dfferent, though it's been discussed on those other issues.

[caitp]

I'm with @frfancha we shouldn't be changing the model value at all because of these transforms. We do need the transforms for the maxlength and other validators to work, but it just doesn't make sense to transform the model value too there.

[frfancha]

caitp, thanks for the quick answers. It is really comforting. It was a very big decision for us to fully switch to angular 10 months ago, and today while testing 1.3 nothing was working anymore in our applications we were quite disappointed.

[Narretz]

I have tried to explain in #9913 (comment) why the modelValue is transformed to string on init - feedback welcome. Basically, it's a combination of the string formatter, and the observers inside the validators firing immediately after init, either because ng-repeat messes with init order, or because the observer fires after the ngModel init.

[frfancha]

Hi, as you explain with the date example, parser/formatter can go from a date object in model to the string representing this date in view and vice versa.
In the view you have a string, and in the model "something".
When you want to apply "string" validation, you must use the "view", the string version, and not the object. How do want to apply a "maxLength" on a date object ?
So using validation must not transform view to model.

And there is something worse but I can't find a simple way to reproduce it: even without the maxLength attribute, in some of our complex screens angular still can't wait the parser/formatter and transforms number to string.
I can't find a simple case to demonstrate it, I'm only able to "smell" that it happens at the same place as the maxLength does the transformation, and that if the maxLength problem is fixed most probably the more complex case will be fixed also.

[Narretz]

the length validators always validate the $viewValue. This is the only way it makes sense. Complex max / min validations exists for date and number, or must be provided by the developer. So maxlength does not transform the value. It's all textbased input types that do it.

Do you have an example where the problem happens with a date input type? I'd be very interested to see that.

[frfancha]

You say: "the length validators always validate the $viewValue"
I totally agree with you that this is the only way to use. But then... why is the model recomputed in the process?

Our "complex" problem occurs also with numbers (the date case was only mentionned to illustrate why the viewValue must be used to validate).