Description
Which @angular/* package(s) are relevant/related to the feature request?
common
Description
Back in the days Angular used Intl APIs in their pipes, but due to different browser implementations this led to many issues. So in 2017, Angular decided to go for a custom implementation, which I think was the right decision at the time. But today we are in a quite different situation. Internet Explorer support has been dropped from Angular, browser support has evolved and the browsers heavily worked on unification of their APIs. In my opinion, it should be re-evaluated whether to switch back to the Intl APIs.
This would have an effect to all pipes which require locale data, namely date, currency, decimal and percent. For developers who don't use compile-time translations it's quite inconvenient to feed those pipes with locale data. Developers need to import from @angular/common/locales/{localeId}, and register the data with registerLocaleData(). When supporting multiple locales, either they all need to be added to the bundle (which bloats up the bundle size), or alternatively they can be loaded with a dynamic import. With the latter solution, additional chunks containing the locale data for each language are generated. Those chunks need to be loaded at runtime depending on the locale of the user. This can lead to missing locale data during the time when the main bundle is already loaded, but the request loading the chunk with the locale data is still pending. The handling of locale data is the main reason why I personally don’t use any of these Angular pipes anymore and wrote own pipes instead based on Intl. I assume I’m not the only one.
Additionally, after a quick search in the GitHub issues, I found that there are some issues with the implementation of the pipes, which could be resolved: #47479 #48279 #48250 #45409 #54114 and more
To list some of the benefits:
- Implementation is much simpler
- Locale data of any locale supported out of the box
- Angular wouldn't need to care about locales at all -> less maintenance effort
- Developers wouldn't need any additional code to register locale data
- The application wouldn't need to load any code related to to locale data
- In general, less pitfalls for the developers
- Falls back to browser default locale if no locale is specified
- Reduced bundle size, because code to register and process locale data at runtime can be removed
Proposed solution
Angular refactors existing pipes to use the Intl.* browser APIs. As this might lead to breaking changes, maybe it would make sense to offer them as an opt-in.
Angular could also consider adding new pipes based on the Intl APIs such as country, language, relativeTime, ..., as they should be relatively easy to implement and maintain.
Alternatives considered
Could also be solved by a community npm package. I'm currently developing one, feedback is very welcome!
https://github.com/json-derulo/angular-ecmascript-intl