-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: use currencyDisplay: 'symbol' #22
base: alpha
Are you sure you want to change the base?
Conversation
size-limit report 📦
|
📊 Package size report 0.6%↑
Unchanged files
🤖 This report was automatically generated by pkg-size-action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this display the currency symbol always? Like on a US Site in USD with a buyer with en_US locale, it will show US $100
?
Or will it only show it if the locale and currency don't match
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prob worth adding new unit tests to cover this addition!
@joe-boudreau yes, it will only show it it doesn't match, like Canadian Dollars in Some interesting edge cases:
Anyways, see the tests for more details |
@kevinlee11 I've also updated it to cache the NumberFormat objects; otherwise we create a new one every time, which is a performance hit. This was called out by @rgershon , thanks Gershon |
* The key is a string representing the locale and currency, | ||
* and the value is the corresponding `Intl.NumberFormat` instance. | ||
*/ | ||
#cachedFormatters: { [key: string]: Intl.NumberFormat } = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was suggested by @rgershon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why? just curious what's going on behind the scenes here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something we're noticing initializing Intl.NumberFormat
as being a heavy operation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so; But we're doing it a lot, and we're just trying to make Lightning Themes as performant as possible and this seemed like low hanging fruit
]; | ||
|
||
currencyAndLocaleList.forEach(({ money, locale }) => { | ||
expect(sdk.helpers.money.formatMoney(money, locale)).toBe(money.formatted); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The output of Intl.NumberFormat.format()
is actually not guaranteed by the Javascript spec, and specifically MDN says we should not compare to a hardcoded string.
However, I think this is fine in a test case; if it starts failing, that would be good to know
This ensures that we see e.g. "CA $100", matching the twig money filter output
69c417a
to
368380a
Compare
@kchung rebased and also marked this as a breaking change, since it changes the text output of a helper |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This ensures that we match the twig money filter output. For clarity about how this functions:
When the currency and locale match, we don't render the country abbreviation. E.g. 100 Canadian Dollars in
en-US
locale will be shown asCA$100
, but inen-CA
it'll be rendered just$100
.