I am not really sure where to post this for it is both LiveView and cross-library related issue so I am posting it here.
What I am trying to do is having form input numbers (amounts) validated and formatted server-side by using ex_cldr_numbers library (which btw, is fantastic, kudos to @kip) while relying on an embedded_schema + changeset based validation.
The limitation I am encountering is as follows. If I use the combination of a
text_input tag and a changeset based validation of the input numbers I don’t see how to validate and display them back in a server-side generated, locale-specific number format (e.g. with the thousand separator such as 1,000,000) since if I store them as :decimal (which is their actual data format) then the text_input tag will show them as numbers without the locale specific thousand separator (or any other desired locale-specific number format).
So, in my view (unless I am missing something big time), I can either choose not to use the
text_input tag but write my own HTML input code mimicking the
text_input output with an additional attribute updated by LiveView and used to override the value attribute in the element JS hook updated callback function, OR I need to have two fields in the schema for each such number (one as a string to read from/write to by the form and the other to store its decimal representation). The latter is so lame that it’s out of the question, so only the former option seems valid but still cumbersome.
Again, unless I am missing something, it would be nice if one of the following two features was added:
a) Either Ecto.Changeset taking an optional transform function when getting a field value (too far fetched maybe?) and having LiveView actually pass it and use it in such a manner, or
b) Have an optional input value-override feature in LiveView to avoid writing own proprietary hooks and manually replicating the
text_input html output in each such case, as previously described.
Trying to replicate the feature rich ex_cldr implementation in JS is also out of the question and the only “light” option remaining outside one of those feature requests is to have such numbers stored in the schema as strings, manage their validation and formatting ourselves and transform them via the same cldr library into decimals with a proprietary function in the data module once the data is required for a later use.