formatNumber - memoizing and getting the parsed pattern

[ragulka]

First: formatNumber uses numberFormatProperties for parsing the pattern into usable properties. However, it seems that the results of parsing are not memoized - which means that the parsing happens every time a number is formatted. This is not optimal as it makes no sense re-parse the same pattern over and over again.

Second: it seems there is currently no way of getting the results of the parsed pattern, ie properties. I am building an application, where the results could prove quite useful - I want to use it in conjunction with the jquery autoNumeric plugin (scroll down for settings) which expects information about the number format as "properties" instead of a string.

[rxaviers]

First: ...

Thanks for poinint that out. But, it's not a coincidence. It's made this way for caching 98a851b. Caching will be introduced soon. Thanks.

Second...

Correct, numberFormatProperties is private and it's not meant to be publicly exposed.

Feel free to hack and use numberFormatProperties from our source code.

[ragulka]

@rxaviers care to reconsider? Hacking/duplicating numberFormatProperties in my app code just so that I could access the parsed properties themselves would be very WET (not DRY at all) and in all ways not optimal.

The codebase around numberFormatProperties is around 100 lines. I don't know about you but when it comes to code-reuse, then (especially in front-end), I'd like to re-use existing code as much as possible and avoid duplication. I couldn't really justify including an extra 100 lines duplicate code just to get the properties that have already been parsed.

I personally don't see why the parsed properties (or a getter) should not be exposed? This information could provide useful in other aspects of app localization. It may be desirable to know how many and which number grouping sizes does the locale use. Also - where to place the currency sign - before or after the numbers? All of this is really useful if you are dealing with form inputs where you need to automatically append or prepend currency sign to user input, etc.

Anyway, I am imagining something like this:

Globalize.formatNumber.properties()

This could then either return the properties of the last parsed/used pattern or optionally a specific pattern/style, and locale.

// returns the properties for the last used style/pattern
Globalize.formatNumber.properties()
// returns the properties for the currency pattern/style of the current locale
Globalize.formatNumber.properties('currency')
// returns the properties for the currency pattern/style of the 'en-IN' locale
Globalize.formatNumber.properties('currency', 'en-IN')

[rxaviers]

Reopening for revaluation.

[rxaviers]

Note to self: Expose it as a NumberFormat class as per http://www.ecma-international.org/ecma-402/1.0/#sec-11.1.3.1?

[baohouse]

Actually it's exposed as Intl.NumberFormat.prototype.resolvedOptions()
http://www.ecma-international.org/ecma-402/1.0/#sec-11.3.3

[rxaviers]

Thanks

[rxaviers]

This issue is about two things: allowing to cache formattes/parsers and exposing the results of the parsed pattern.

Caching is partially implemented by #470. If you want such support, please weigh in that issue. Let's focus discussion there.

Accessing results of the parsed pattern is possible via the exposed runtimeArgs (available on Globalize 1.1):

var fmt = Globalize('en').currencyFormatter('USD')
fmt.runtimeArgs[0].runtimeArgs[0]
// [...resolved properties...]

I'm not suggesting the above is a solution for this issue. But, at least it could be used today if you need to. I still believe something similar to Ecma-402 resolvedOptions() mentioned above is ideal. So, please feel free to open a new Issue or Pull request suggesting an API. I'm closing this issue due to lack of activity.