You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
By default, no global formats are available via format.* calls. However, for consumption in messages, a few defaults are available through intl-messageformat (source).
Describe the solution you'd like
Ideally, we'd support the same defaults across both options.
The options I can currently think of are:
Importing formats from intl-messageformat for local consumption (big downside: pulls in the whole dependency, so not really an option).
Re-defining the formats for both places (downside: duplication with intl-messageformat)
Using no defaults in either place
After feat: AOT compilation with icu-to-json (experiment) #705, we'll get rid of intl-messageformat at runtime and also gain more control over aspects like defaults, so we could consider supporting the same defaults for both APIs without duplication
I'm currently favoring (3), but this would be a breaking change.
Describe alternatives you've considered
User has to define all relevant formats in user space. These apply to either functionality.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
By default, no global formats are available via
format.*
calls. However, for consumption in messages, a few defaults are available throughintl-messageformat
(source).Describe the solution you'd like
Ideally, we'd support the same defaults across both options.
The options I can currently think of are:
formats
fromintl-messageformat
for local consumption (big downside: pulls in the whole dependency, so not really an option).formats
for both places (downside: duplication withintl-messageformat
)icu-to-json
(experiment) #705, we'll get rid ofintl-messageformat
at runtime and also gain more control over aspects like defaults, so we could consider supporting the same defaults for both APIs without duplicationI'm currently favoring (3), but this would be a breaking change.
Describe alternatives you've considered
User has to define all relevant formats in user space. These apply to either functionality.
The text was updated successfully, but these errors were encountered: