Liveview won’t update inputs, which are focused anyways. So no matter what you do you cannot live replace the text in an input as user currently writes to without additional js. Given the latency of liveview I’d also strongly suggest to not even try to format input field values server side. I even had problems with js libraries being quite annoying by trying to format while supplying input (and in the mean time screwing up what I intended to write).

There are imo three options (from most to least prefered in my opinion):

• Don’t do it
  Just let users supply number is whatever format they want to and apply formatting only afterwards. If you’re worried about incorrect inputs opt for making corrections easier or show a formatted preview next to the input.

• Use JS library
  There are js libraries created for formatting input with delays or while writing. If they support cldr you might eben be able to supply patterns of ex_cldr to them.

• Take on the complexity head on
  With client and server doing concurrent edits to text you’re tech. dealing with distributed state. One way to handle that could be using delta-elixir, which slab released recently, and the js counterpart and actually treat the changes made to the text like distributed changes, which need later consolidation. This is overengineering at its finest for your usecase, but I wanted to include it just to show the level of complexity the core of the requested functionality entails.

Actually, that’s not even necessary if opting not to format the number while the user is typing for which I agree with @LostKobrakai that thriving for the “ideal” solution may seriously impair UX which is why I am now using a focusout listener to detect when form inputs lose their focus and then simply push a proprietary event to my component e.g.:

function maybeFocusoutOfModalInput( me, e) {
  if( !isInput( e.target) || !isOfClass( e.target, MODAL_NUMBER_CLASS)) return false;

  me.__view.pushInput( e.target, e.target.form, 'rerender', e.target, null);
  return true;
}

With the following input tag in the template:

<%= text_input f, :amount, class: “modal-number-input”, value: @changeset.changes[ :amount] && CldrHelpers.amount( @changeset.changes[ :amount]) %>

Note that the ‘rerender’ handle_event is not really a rerender but has the effect of it as it simply recreates a changeset based on the provided form parameters (since, as per LiveView docs, JS is the single source of truth here).

And that’s it. No need for additional JS code.

I like the idea of letting the browser format the user’s number natively, and pretty-formatting it for the specific context on focus out. This is the way of least surprise for the user as the number input will behave in the same way as it does in other sites, and other apps when on mobile.

Following this frame of mind I wanted to test the native options for internationalization at our control. The result is the gist HTML5 input number localization study (codepen.io).

I wanted to see how Edge(Chromium) and Firefox behaved while influencing the localization of decimal number inputs.

From the input implementation notes in the HTML Standard (whatwg.org)

The formats shown to the user in date, time, and number controls is independent of the format used for form submission.

Browsers are encouraged to use user interfaces that present dates, times, and numbers according to the conventions of either the locale implied by the input element’s language or the user’s preferred locale. Using the page’s locale will ensure consistency with page-provided data.

The main point of study was how browsers interpret , and . for fractions of a number, and as a bonus how to influence the virtual keyboard presented to the user.

0.1 is a default representations of a floating-point number in the HTML Standard (whatwg.org), the other being exponent notation.

Setting the element’s lang attribute will influence whether value sanitization algorithm (whatwg.org) recognizes or ignores , as a valid decimal. The value must be a valid language tag (WAI) | W3C.

Set up

Configure two number inputs, individually displaying their value attributes and a text representation of their checkValidity() results.

Method

Test out each step in latest Edge and Firefox browsers.

1. Step each input’s value up by clicking the spinner arrow
2. Manually overwrite the inputs with 0,1
3. Manually overwrite the inputs with 0.1

Results

Firefox

1. Clicking the arrow on input en-CA makes the display use . as decimal, whereas fr-CA defaults to localized display of ,
   

   

   image417×168 3.18 KB

2. Both inputs recognise . as decimal
   

   

   image413×166 2.89 KB

3. Default language en-CA does not use , as decimal, so value is not valid.
   

   

   image481×165 3.28 KB

Edge(Chromium)

1. Changing the value with the spinner causes both values to display with , as decimal?
   

   

   image372×158 2.51 KB

2. Both inputs recognise . as decimal
   

   

   image362×163 2.49 KB

3. Input value does not care that , is not valid for en-CA, it parses it to a valid float anyway!
   

   

   image358×162 2.5 KB

Moral of the story is that <input type=number> is not treated equally in different browsers.

Anyone willing to post their results below for other browsers, like Safari, please go ahead.