internal date/number formatters are not reexported from @angular/common

[iexela]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Starting from the version 5 Angular uses CLDR data for number/date/currency internalization. It uses internal formatters for this purpose and does not reexports them to be available for developers. I mean formatters describes in these files: format_date.ts, format_number.ts.

Expected behavior

Reexported formatters will allow to localize data in code.

What is the motivation / use case for changing the behavior?

Sometimes it is necessary to translate dates or numbers in code rather than in templates.
For example, when we use 3rd-party components, like ag-grid, we can define custom formatters for date represented in grid and it will be a large overhead to use Angular component for this purpose. Much easier is to use formatting capabilities embedded into Angular itself to reach consistent formatting.
Another case is messages generated in code.

Environment

Angular version: 5.x.x

[trotyl]

Relates to #3809, #15107.

[vicb]

Our intent with the refactoring in 5.x was to make this publicly available at some point.
We will do that at some point when we have some confidence in the new API.
(A lot of devs are using the pipes to format dates & numbers in their code today which is definitely not a good thing)

[Toxicable]

I had the idea to put those date functions in a service rather than just exporting a bunch of functions but due to the services not being tree shakable I didn't proceed, maybe once that's a thing we could take a look back at it?

[iexela]

Injection of date pipe solved my problem, thank you.
Although from my perspective this solution looks like a workaround.
Glad to hear that you have plans to make format API public.

[alan-agius4]

Yeah same thing I hate to inject the pipe, it does feel wrong.

i like the service approach, TBH, as like that when you use a method you dont’t need to provide the LOCAL_ID, as some pre functions that there are available require the localId as param at the moment.

Maybe as a starter you can export these method similar to what you are doing for other methods like getLocalCurrencySymbol?, since really I dont know when we’ll have treeshaking on services.

I’ll gladly do a PR if it is needed :)

[Toxicable]

It would be better to do a proper job of exporting these functions with a Design Doc and as a service specifically designed for this.
Doing a half job by exporting random functions into the public API can force us into a bad position if we want to come back and refactor it into a service later

[alan-agius4]

I agree with that, but whats the different between the ‘format’ and the ‘getLocale’ methods like such: https://angular.io/api/common/getLocaleNumberFormat that the format methods needs to be in a service and the others as exported methods? Don’t get me wrong I am in favor of the service, but maybe in that case the current exported functions should go in the service as well than? So not to have half of the methods exported and the other half in a service. But as you mentioned there is the overhead of not being tree-shaked.

…

On Thu, 28 Dec 2017 at 21:59, Fabian Wiles ***@***.***> wrote: It would be better to do a proper job of exporting these functions with a Design Doc and as a service specifically designed for this. Doing a half job by exporting random functions into the public API can force us into a bad position if we want to come back and refactor it into a service later — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20536 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQv-Wimkg_YvuDySqFOSxlsze1jO6QJdks5tFAFIgaJpZM4Qj1AI> .

[ocombe]

It's on our todo list to export those functions, but we need to refactor them a bit to make them easier to use by anyone.