Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
internal date/number formatters are not reexported from @angular/common #20536
I'm submitting a...
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.
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.
Our intent with the refactoring in 5.x was to make this publicly available at some point.
referenced this issue
Dec 28, 2017
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 :)
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.
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> .