Format currency input with commas in household input

[abhcs]

Fixed #178 by using the formatter property in ant-design InputNumber component. Renamed locale en to en-GB, the standard Unicode identifier for the English language in the UK region (see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale for details). Improved the interface for locale-related functions with better names and documentation.

Tested in UK and US locales to verify that currencies are displayed properly in inputs and charts.

🤖[deprecated] Generated by Copilot at 63f4416

Summary

🌐💷📊

This pull request improves the localization of currency values and plotly charts in the policy engine app. It introduces two new functions, localeCode and currencyCode, to get the appropriate codes for a given country. It also updates the VariableEditor component and the output charts to use these functions and the native toLocaleString method of numbers. It also renames and updates the UK English plotly locale module.

Oh, we're the jolly coders of the policy engine
We format currencies and locales with ease
We use localeCode and currencyCode to make it clean
And we heave away on the pull request with a breeze

Walkthrough

• Replace currencyString and localeString functions with localeCode and currencyCode functions in src/api/language.js to return locale and currency codes for a given country id (link)

• In src/pages/household/input/VariableEditor.jsx, update the formatter prop of the InputNumber component in the HouseholdVariableEntityInput function (link, link)
• In src/pages/policy/output/AverageImpactByDecile.jsx, update the text prop of the bar trace in the AverageImpactByDecilePlot function (link, link)
• In src/pages/policy/output/AverageImpactByWealthDecile.jsx, update the text prop of the bar trace in the AverageImpactByWealthDecilePlot function (link, link)
• In src/pages/policy/output/AverageImpactByDecile.jsx, update the locale prop of the Plot component in the AverageImpactByDecilePlot function (link)
• In src/pages/policy/output/AverageImpactByWealthDecile.jsx, update the locale prop of the Plot component in the AverageImpactByWealthDecilePlot function (link)
• In src/pages/policy/output/BudgetaryImpact.jsx, update the locale prop of the Plot component in the BudgetaryImpactPlot function (link, link)
• In src/pages/policy/output/DetailedBudgetaryImpact.jsx, update the locale prop of the Plot component in the DetailedBudgetaryImpactPlot function (link, link)

• Rename src/plotly_locales/locale-en.js to src/plotly_locales/locale-en-gb.js and change the name property of the loc_en module to en-GB to reflect the correct locale code for the UK English plotly locale (link)
• Update the import and registration of the UK English plotly locale in src/redesign/components/PolicyEngine.jsx to use the renamed loc_en_gb module (link, link)

[nikhilwoodruff]

Thanks @abhcs - how does this handle user input? Just to check that if a user sees commas and changes the value to a string including commas that this wouldn't break the app.

[abhcs]

The formatter property changes the display string on each event. The user will be unable to type the string 1,234 in the normal way because at 1,2 the output will get reformatted to 12.

input	display
1	1
1,	1,
1,2	12
1,23	123
1,234	1,234

Note that the current component also reformats the display string similarly but does not add commas. This is an unavoidable side-effect of "formatting in real time" (#178); see also the formatter example at https://ant.design/components/input-number.

If one were to directly paste the string $123456 into the new component, then it would get reformatted to 123,456. In the current component, it would get reformatted to 123456.

[anth-volk]

This looks like a great change. I tested locally and can see that your edits do handle the comma properly, as well as clipping out garbage values. That said, per the video I've included here, the edits don't properly format an input sub-dollar unit divisible by ten; for instance, if I input "$15,000.30", it shortens this to "$15,000.3". So, to proceed, I'm wondering if you'd be willing to do the following:

1. Investigate if there is an antd setting that always displays two decimal places if the input number contains a decimal point (at least after the user is no longer focused on the box)
2. Remove the default "0" that's displayed when nothing has been input, and instead have the box be empty, as it is currently on the live app
3. Rebase off of master

Thanks so much for your contributions to the app!

Screen.Recording.2023-12-11.at.4.43.43.PM.mov

[anth-volk]

Screen.Recording.2023-12-11.at.4.43.43.PM.mov

Hopefully the video uploaded correctly in this comment

[anth-volk]

Apologies, I should've left my comments here, but please see my comments on the PR itself

[abhcs]

This looks like a great change. I tested locally and can see that your edits do handle the comma properly, as well as clipping out garbage values. That said, per the video I've included here, the edits don't properly format an input sub-dollar unit divisible by ten; for instance, if I input "$15,000.30", it shortens this to "$15,000.3". So, to proceed, I'm wondering if you'd be willing to do the following:

1. Investigate if there is an antd setting that always displays two decimal places if the input number contains a decimal point (at least after the user is no longer focused on the box)

In the OnChange handler for InputNumber, we get a value of type string but it has already lost its trailing zeros. The conversion of the input to this string is handled by antd; thus, the internal logic of InputNumber is responsible for the good behavior, e.g., removing elements like $. The formatter never sees the input $15,000.30, it only sees 15000.3 provided by antd. There are properties like stringMode in InputNumber that may be worth exploring but we would lose the abstraction of InputNumber.

The abstraction of InputNumber is an important one. Notice in the image below how the zeros after the comma are ignored when we just use Input in ParameterEditor:

2. Remove the default "0" that's displayed when nothing has been input, and instead have the box be empty, as it is currently on the live app

Since pull request #892, the default is displayed as 0.00. The current request changes this to 0.

3. Rebase off of master.

Done.

Thanks so much for your contributions to the app!

You are welcome.

[abhcs]

The new commits should fix #928. Now, I am using the formatter property for all floats. Despite age being a float, the trailing zeros get stripped.

[anth-volk]

I've been digging into this to see if we can get it to display two decimal places only after the user clicks outside the input, as doing it before prevents the user from inputting a second decimal place without hitting backspace. I'll come back to it tomorrow.

[abhcs]

Please check the latest commit. It may do what you are looking for; otherwise, we can revert it. It uses a strange combination of formatter and precision, which seems to work.

[anth-volk]

I've taken the liberty of making a minor edit: In Ant Design, the precision feel is overridden whenever a formatter is present, meaning your last commit unfortunately didn't have its intended impact. However, there's a pretty hidden userTyping param that allows for conditional formatting based on whether the user's actively engaging with the box, so I've edited it to format decimals only when the user isn't typing.

Thanks again for digging deep into antd's docs, @abhcs.

Edit: Just waiting to push until the checks finish

[abhcs]

The docs say that precision is overridden by formatter but the solution was working! It was allowing the user to type an arbitrary number of fractional digits but the precision was getting applied on blur, i.e., not typing. I think that using userTyping is a better solution though. See PR #962.

[anth-volk]

Very strange, perhaps your version was different from mine? When I installed and ran yours locally, the overriding did occur…not sure why.

…

On Dec 13, 2023, at 8:26 PM, Abhishek Singh ***@***.***> wrote: The docs say that precision is overridden by formatter but the solution was working! It was allowing the user to type an arbitrary number of fractional digits but the precision was getting applied on blur, i.e., not typing. I think that using userTyping is a better solution though. See PR #962 <#962>. — Reply to this email directly, view it on GitHub <#941 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSK7W6YBLFSZW4HLS7VXXTYJJPWFAVCNFSM6AAAAABALOLR46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJVGAYDSOJUHE>. You are receiving this because you modified the open/close state.

[abhcs]

Yeah, its best not to depend on undocumented quirks in any case. So userTyping is a better solution. Maybe it was browser-specific. I am using Safari.

[anth-volk]

Ah, that could be it. We’ve had cases before where Safari will do one thing and all other browsers do another for some reason.

…

On Dec 13, 2023, at 20:32, Abhishek Singh ***@***.***> wrote:  Yeah, its best not to depend on undocumented quirks in any case. So userTyping is a better solution. Maybe it was browser-specific. I am using Safari. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.