Internationalized input format

[mmannes]

Hello,

I have a use case where the user should be able to use her/his local decimal separator. E.g.: Thaw's InputNumber component require using . (dot) as decimal separator. Other countries use , (comma) as decimal separator.

I was thinking about implementing leptos-use's use_intl_number_format inside Thaw's InputNumber. What do you think about it?

If adding another external dependency is something you are not comfortable, I could use web-sys in order to get the user's locale data.

It could be implemented like a Thaw's feature. Developers should opt-in to "intl" feature of Thaw when adding it as a dependency.

Same could be implemented for DatePicker component as well.

[luoxiaozero]

Hi, I'm more inclined to realize the underlying function (e.g. https://www.naiveui.com/en-US/light/components/input-number#parse.vue), advanced features can be secondary development. But I'd like to hear your thoughts on how to implement this function.

If adding another external dependency is something you are not comfortable, I could use web-sys in order to get the user's locale data.

You can add leptos-use, I won't be uncomfortable.

[mmannes]

I see. I have completely missed the point that Thaw implements most of the functionality from Naive UI. Now I get it and that can work for me. Not only that, but I can try to implement it, and we can share more thoughts about it. Probably having the parse and format attributes that, receive a function each, should do the work just as Naive UI does.

The thing I don't like about explicitly format numbers in the front-end is that the OS and the Browser already know the user's preferred locale and, anytime the user have to fill any form, it should already have the right format. I believe that in this case, having a good default behavior is better than asking the developer to create functions to do what probably could be there by default. But I also get the fact that Thaw tries to mimic the Naive UI implementation, this is also a good thing.

If we were not bound to the Naive UI implementation, I would suggest that, using leptos-use's use_intl_number_format we could be able, by default, to format and to parse numbers based on the browser's locale. The underlying value should always be an i32 or f64.

By the way, it is a bliss working with Thaw! Thank you!

[luoxiaozero]

The thing I don't like about explicitly format numbers in the front-end is that the OS and the Browser already know the user's preferred locale and, anytime the user have to fill any form, it should already have the right format. I believe that in this case, having a good default behavior is better than asking the developer to create functions to do what probably could be there by default.

Agreed, we can do it the way you say. Based on this, we can add an optional language parameter to allow customization.

---

https://primevue.org/inputnumber/#locale

[luoxiaozero]

One thing we did not consider is that the Intl object of js does not exist in SSR mode, which will lead to inconsistencies between CSR and SSR. For example:

fn InputNumber(value: RwSignal<i32>) {
    let input_value;
    #[cfg(feature = "ssr")]
    {
         input_value = ??? // What to do here?
    }
    #[cfg(not(feature = "ssr"))]
    {
         input_value = Intl.NumberFormat('de-DE').format(value.get_untracked());
    }
    view! {
         <input value=input_value />
    }
}