Closed cwallervand closed 5 years ago
Creating Intl instances is way more expensive than creating JS objects. e.g.:
new Intl.NumberFormat(location, options);
Since it requires ICU/CLDR underlaying integration, which requires some bridge crossing from the engine to ICU, this operation is slow. Intl.MessageFormat
is not part of the engine just yet, but it relies on the creation of a plural rule instance (https://github.com/tc39/proposal-intl-plural-rules/) and/or number format instance, which makes this expensive.
Moving all the logic to the .format
is doable, but you will get penalize for extra operations during format, and introducing a setOptions() method diverge from other standard Intl mechanism, and IMO buy us little.
Hey.
It would be great if it was possible to set formatting options after creating the IntlMessageFormat object. Something like this:
In many cases where we format numbers we use the same message template, but with different formatting options e.g. with two decimals, without decimals, etc. Being able to set format options after creating the IntlMessageFormat object means that you dont have to create a new object instance, which we do now. This can affect performance of applications when objects are created and destroyed rappidly.