input[number] does not initialize when ng-model is a string ("123")

[nonplus]

When you have an <input type="number" ng-model="value"/> and the value is a string containing a numeric value (e.g. "123"), the input control is blank. If a value is a numeric (e.g. 123) the control value is properly initialized.

I would expect that both a model number 123 and a string "123" would initialize the input the same.

http://jsfiddle.net/nonplus/23SJ9/3/

Reproducable in Chrome and FF against AngularJS 1.2.10.

BTW, this looks like a duplicate of #1126 although that one seems to be also dealing with formatting.

[caitp]

This doesn't seem unreasonable, I'll post a fix, maybe it can be merged shortly.

[Narretz]

In 1.3.x, intializing with a non-number will now throw an error. This was done because it's too fragile to try an convert strings to number automatically. Since this would introduce a breaking change into 1.2.x, I'd say this is wontfix for this branch.

[olleicua]

This seems bad to me as JavaScript is not strongly typed and there appears to be no work-around.

[caitp]

wouldn't you say the work around is to make sure you're using numbers, so that you don't accidentally footgun yourself when you have a string instead?

[olleicua]

That's easy enough when you are building a project from scratch with angular in mind. I'm currently adding an angular ui to an existing large project. I get data from several endpoints which I cannot always control. In the ideal world I would be able to convert everything that goes in a number field to a number before angular sees it but angular is intended to be a general purpose front-end framework and it would be trivial to for example add a configuration flag somewhere that would let angular do this for me. It could even use something like (parseFloat(val) + '') === val to make sure the string is a valid number.

I tried putting a custom directive on all of my input[type=number] tags but I couldn't find a way. The value was being invalidated before I could get any hooks in.

Javascript is a dynamically typed language, this is a reasonable use-case, and I'm disappointed that Angular has no interest in supporting this.

[recurrence]

Agreed, there should be a casting mechanism. Was surprised this coercion was not handled since it is so pervasive in javascript.

[rizen]

Figured out a way to pull this off: https://gist.github.com/rizen/5f76357f6758dd8f6f74

[blackdynamo]

How is this still an issue in 2016?

[gkalpak]

It's not an issue - it is expected behavior 😃
Fortunately, Angular is flexible enough to let you change it, using an appropriate custom directive (if you absolutely need to).

[nonplus]

Clearly that behavior wasn't expected by me and others on this thread, otherwise I wouldn't have filed a case. Though apparently it is now documented behavior as of Angular 1.3.1.

@rizen, thanks for your fix, works great.

FWIW, I don't want to be casting stones here since I've used the "it's not a bug, it's a feature" excuse myself and told clients of my code to RTFM and "work around it". But "fixing" unexpected behavior via documentation always made me feel a bit dirty. ;-)

[rizen]

You're welcome @nonplus

[blackdynamo]

If it was/is intended behaviour, that's fine, it's just that it seems a little funky and not obvious until something bad happens. Sure you get a console message but 99.99999% of users don't even know what the console is. All they end up saying is "where is my data?" It would have been nice if the value would end up in the field but trigger validation and ng-messages.

Anyway there is a work around, so thanks @rizen