Skip to content
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

Design for currency and unit inputs that carry their values #911

Open
sffc opened this issue Jul 18, 2024 · 5 comments
Open

Design for currency and unit inputs that carry their values #911

sffc opened this issue Jul 18, 2024 · 5 comments
Assignees
Labels
c: meta Component: intl-wide issues Proposal Larger change requiring a proposal s: in progress Status: the issue has an active proposal

Comments

@sffc
Copy link
Contributor

sffc commented Jul 18, 2024

Rather than setting the unit/currency in the constructor, should it also be carried in the type being formatted?

Might be wanted by Intl.MessageFormat.

CC @eemeli

@sffc sffc added s: discuss Status: TG2 must discuss to move forward c: meta Component: intl-wide issues labels Jul 18, 2024
@aphillips
Copy link

@sffc: in the constructor of what?

A currency value should carry its currency code (and not just a number) around. A unit amount should likewise not forget it's unit.

@sffc
Copy link
Contributor Author

sffc commented Jul 19, 2024

Currently one needs to set the currency or unit in the constructor of Intl.NumberFormat, and the .format() function takes only the number. The ask is for the unit and currency to be passable directly into .format().

@eemeli
Copy link
Member

eemeli commented Jul 19, 2024

For context, the MF2 spec currently includes this for its :number options:

The following values for the option style are not part of the default registry. Implementations SHOULD avoid creating options that conflict with these, but are encouraged to track development of these options during Tech Preview:

  • currency
  • unit

To accommodate this and still allow e.g. currency formatting, the Intl.MessageFormat proposal's :number handler accepts as input numbers, BigInt, JSON string representations of numbers, or objects with a valueOf() method that returns a number or a BigInt. When using that last form, the object may also have an options property, and its values are merged into the MF2 expression options, and eventually passed to the Intl.NumberFormat constructor.

This allows for usage like:

const msg = new Intl.MessageFormat('en', 'Your total is {$price :number style=currency}')
const price = { valueOf: () => 42, options: { currency: 'EUR' } }
msg.format({ price }) // 'Your total is €42.00'

This kinda works, and seems like the least worst option at the moment. But it still feels somewhat hacky, esp. as it doesn't differentiate options like unit and currency as anything special.

It might be better to have some more explicit representation of number+currency and number+unit that could be supported also outside Intl.MessageFormat, in Intl.NumberFormat.

@sffc sffc moved this to Priority Issues in ECMA-402 Meeting Topics Aug 22, 2024
@sffc
Copy link
Contributor Author

sffc commented Oct 3, 2024

@sffc
Copy link
Contributor Author

sffc commented Dec 16, 2024

@sffc sffc added s: in progress Status: the issue has an active proposal Proposal Larger change requiring a proposal and removed s: discuss Status: TG2 must discuss to move forward labels Dec 16, 2024
@sffc sffc moved this from Priority Issues to Previously Discussed in ECMA-402 Meeting Topics Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: meta Component: intl-wide issues Proposal Larger change requiring a proposal s: in progress Status: the issue has an active proposal
Projects
Status: Previously Discussed
Development

No branches or pull requests

4 participants