type='number' and value-as-number

[David-Mulder]

So, right now bind-value always returns a string. There are two ways this could be fixed:

• Like the HTML5 spec adding a value-as-number property (which would still allow two way binding to the value)
• Or simply making value a Number if type is set to Number

Personally I vote for the second option, but I would love to see this fixed.

[notwaldorf]

We tried adding bindValueAsNumber before (https://github.com/PolymerElements/iron-input/pull/58/files) and it was a bit of a disaster. Basically, it adds so much custom code that we didn't think it would be maintainable in the long run, for the fairly little value it adds. So that's not really an option.

Changing the type of value at runtime is also a bit icky, because compilers will complain. And since bindValue is propagated up to paper-input, which might use it for validation, this is going to be a bit of a disaster.

Ideally, in a perfect world, what I would like to do is step away from this type antipattern, and have separate elements for each of these different input types (like iron-input-number, which has its value and bindValue as a Number, and Always Does The Right Thing™️).

TLDR: I'd like to punt on this until we have a better solution. But it's in like my top 3 things to fix this quarter.

[David-Mulder]

@notwaldorf Replying a bit late (busy during this part of the year), but what issues are there with the suggested pull request? I have been using that in production for awhile now without any issues. The advantages are:

• If you use a <paper-input type="number"> you can actually use the bind value in calculations
• If the bound value is a number it won't cause the caret to jump around erratically whenever the bound value is changed in to a number (as right now iron-input thinks the value changed). To see an example of this try editing the number fields at the bottom of this page: http://david-mulder.github.io/paper-datatable/components/paper-datatable/demo/paper-datatable/editable.html (don't have the fix right now applied in my github pages, pain in the *** to maintain it there)

[indolering]

Gentle ping: given that Polymer cannot reliably perform 2-way binding on numeric inputs in IE/Edge, I think this bug deserves a higher priority. I can't even get 1-way binding of numeric inputs working reliably with iron-list : (

[indolering]

Ideally, in a perfect world, what I would like to do is step away from this type antipattern, and have separate elements for each of these different input types.

What if instead of numeric input we offered a generic value transform function? That feels like a natural extension of iron-input's custom validators and preventInvalidInput functionality. It's not a replacement for a numeric input element, but it would serve as a solid base for one.

Update: moved this suggestion to a new ticket.

[lpellegr]

Any updates? I am facing the same issue.

[notwaldorf]

I'm going to close this issue since I don't think it will ever be implemented