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

Allow providing default formats for when no option is passed to formatter #1654

Open
killianhuyghe opened this issue Jan 10, 2025 · 2 comments
Labels
area: ergonomics enhancement New feature or request

Comments

@killianhuyghe
Copy link

Is your feature request related to a problem? Please describe.

I'd like to be able to control what is the default format when no option is passed to format.*.

In particular, the default number formatting options in my app are { maximumFractionDigits: 2 } and I find myself having to use a specific option string with every use of format.number (e.g. format.number(n, "default")).

I am dealing with a lot of financial data in my app and the original defaults for most locales seem to keep (maximum) three decimal digits, which doesn't make sense in my app.

Describe the solution you'd like

I wish I could pass my global defaults in my config:

import {getRequestConfig} from 'next-intl/server';
 
export default getRequestConfig(async () => {
  return {
    defaultFormats: {
      number: {
        maximumFractionDigits: 2
      }
    },
    formats: {
      precise: {
        maximumFractionDigits: 5
      }
    },
 
    // ...
  };
});

and have format.number(n) use these default formats.

Describe alternatives you've considered

The two main alternatives I have considered are:

  • use a custom global format and always call with an option string like format.number(n, "default") (note that this choice of option string both makes sense and is silly as one can argue default is when no option is provided)
  • use a wrapper like
const useNumberFormatter(() => {
  const format = useFormatter();
  return (n, options) => format.number(n, options ?? defaultOptions);
}

but then you have one of the formatter that doesn't use the format.* function, leading to potential inconsistencies (or you can wrap every formatter and just always import your wrappers).

I know the alternatives are not too bad, yet I find none of them very satisfying.

@killianhuyghe killianhuyghe added enhancement New feature or request unconfirmed Needs triage. labels Jan 10, 2025
@amannn
Copy link
Owner

amannn commented Jan 13, 2025

I see your point, yes.

While technically we could provide a default for useFormatter, we can currently not apply one when formatting a number as part of a message. That's due to the reliance of this library on intl-messageformat. In case we get rid of this library, a default format could be considered to consistently work across both useFormatter and messages. Without this guarantee of consistency, I'm afraid it would be a bit too easy to introduce subtle bugs. Closely related: #758 (comment).

the original defaults for most locales seem to keep (maximum) three decimal digits

Can you share some examples of locales where the default configuration of number formatting varies? I didn't know this is the case.

@amannn amannn added area: ergonomics and removed unconfirmed Needs triage. labels Jan 13, 2025
@killianhuyghe
Copy link
Author

Hey @amannn , makes sense, thanks for the answer.

Regarding the number formatting, it doesn't vary for the decimal (default) style, I just didn't check the doc at the time (from mdn):

The default values of maximumFractionDigits and minimumFractionDigits are 3 and 0, respectively.

In case that helps someone, I am currently considering these names for global formats:

  • decimal -> same name as the style, consistent with percent, currency
  • .##, .00, %, ... -> short, specific, consistent with ICU number skeleton syntax

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ergonomics enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants