x-model.number comma or dot as decimal separator erases field

[janzikmund]

Hi,
in our project some users use comma (,) while others use dot (.) as decimal separator and we want to support both on numeric inputs.

When I use <input type="number" x-model=".."> field, it indeed lets them type both kinds, and behind the scenes commas are replaced by dot in Alpine component property. So no matter if they type 3.14 or 3,14, Alpine model gets "3.14", which I can parseFloat() and use for calculations.

I would love to use .number modifier, so I get real numbers, not Strings, and can sum them already without transformation. But when I apply the .number modifier like this <input type="number" x-model.number="..">, then suddenly only one decimal separator becomes possible based on user's locale. And when user presses the other, it erases the whole field.

I made a fiddle to showcase this:
https://jsfiddle.net/janzikmund/otmh72Ld/9/
The upper input is the .number one, so as you type numbers there, when you press comma or dot (based on your locale), the whole input gets erased.
The bottom field is without the modifier, supporting both. But with the downside of returning values as Strings, so I always have to parseFloat() them for any calculations.

Apparently the field erase only happens when the alternate decimal separator is added as last character - when I type 2222 and then move cursor back and type the decimal separator in between, both dot and comma work. But that's a terrible walkaround, users should be allowed to type freely.

Is there anything I am missing, and is there a way to do it with x-model.number? Or is it supposed to be locked for single decimal separator only? Thanks a lot for any suggestions.

[ekwoka]

You just kind of can't.

It's an edge case you should handle in your code since there just isn't really much to do about it.

so I always have to parseFloat() them for any calculations.

always or you write that code once?

[janzikmund]

always or you write that code once?

I meant whenever I use the field value. The form is rather complex, we use calculations across rows, columns, some fields depend on other field's values etc. So would be more transparent if I could use the model value directly, rather then always wrapping it with parseFloat.

But I see your point, I tried my own implementation, something like :value="myval" @input="myval=parseFloat($el.value)" but it suffered the same issues as with x-model.number.

[SimoTod]

You can just add an additional getter that calls parseFloat and use the decorated field anywhere else

[janzikmund]

Thanks, but unless I am not mistaken, the the getter cannot have the same name as an existing property. So for any field, I will have to have a getter with different name. That will become even more confusing and introduce new variables with proper formatting, while the old ones are still available.

[ekwoka]

🤔 is it better or worse than calling parseFloat? Wouldn't myvalAsNumber solve it pretty easily?

[janzikmund]

sure, it's just something to consider. But neither of them is as nice as having the value as Number directly from x-model 😉