Closed David-Mulder closed 6 years ago
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.
@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:
<paper-input type="number">
you can actually use the bind value in calculationsiron-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)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
: (
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.
Any updates? I am facing the same issue.
I'm going to close this issue since I don't think it will ever be implemented
So, right now
bind-value
always returns astring
. There are two ways this could be fixed:value-as-number
property (which would still allow two way binding to thevalue
)value
aNumber
iftype
is set toNumber
Personally I vote for the second option, but I would love to see this fixed.