Components: feat(datepicker): Add additional date adapter implementations

[jelbourn]

This issue tracks creating additional date adapter implementations in addition to the existing MomentJS implementation. Libraries to consider include:

• [ ] Luxon
• [ ] date-fns
• [ ] Day.js

[andriyor]

Consider of using date-io

[ahmadalfy]

Voting for date-fns. Moment.js entered maintenance mode.

[paxforce]

+1 @ahmadalfy go for date-fns!
It's lightweight & fast.

[mtpultz]

I'm hoping by subscribing to this feature request for updates with Moment entering end of life that this doesn't mean I'm going to get a bunch of emails with everyones vote/opinion on which adapter implementation should be considered based on your own personal preference. Seems more logical to expand the list put forth by @jelbourn like @andriyor has since it wasn't included in the original list, but not voting individually through posts

[bbarry]

I am wondering if the material components repo is the right place for these things. IMO material should publish the api interface and encourage community contributions for the adapter services. Perhaps an endorsement program or something would be nice with a path to being mentioned in the documentation (a similar system could be useful for a number of projects that I've seen die stale code deaths from lack of updates because the projects fail to gain notoriety for the tiny enhancements they bring to the material ecosystem).

I'm assuming that the moment adapter exists due to use within Google. The only benefit I see to having it in this repo is to gain access to Google's robust build and package system (not always a benefit either; complexity always sucks) and maybe access to some test cases that aren't made public. If those aren't going to advantage these additional implementations then there seems little point to supporting them here (outside the notoriety angle which I think is a PR issue and not really a technical one).

[AwesomeObserver]

date-fns of course

[andriyor]

https://twitter.com/dmtrKovalenko/status/1254414963306909699?s=20

[jelbourn]

The current state of this is that we're still discussing whether this is something we want to maintain as a first-party (Angular team) thing, or instead defer to community implementations of different date adapters. We'll definitely weigh community feedback here.

[MatthiasKunnen]

@jelbourn I've once looked into creating a date-fns date adapter but decided against it because I deemed it a huge hassle to get the necessary testing framework into my own project. If there is a way the Angular team could provide some kind of base for date adapter libraries to build on I reckon third party implementations would be attainable.

[KingDarBoja]

@jelbourn I've once looked into creating a date-fns date adapter but decided against it because I deemed it a huge hassle to get the necessary testing framework into my own project. If there is a way the Angular team could provide some kind of base for date adapter libraries to build on I reckon third party implementations would be attainable.

There is some gist for a date-fns adapter, which I copied onto my project and worked like a charm, but in this case, there is already a base for building your own date adapter via https://material.angular.io/components/datepicker/overview#choosing-a-date-implementation-and-date-format-settings so not sure what you meant.

Cheers!

[MatthiasKunnen]

@KingDarBoja, making a quick implementation of a date adapter is pretty easy. Making a properly tested date adapter and keeping it in sync with changes in Angular is something else. The current MomentDateAdapter has the luxury of residing in the Angular Components source and can use the extensive testing framework that is available.

When a breaking change to the DateAdapter class is made, all third party date adapters will need to release an update to support this so you could have the problem that e.g. Angular 11 releases but your DateAdapter only supports up to Angular 10.

For testing, versioning, and breaking changes it will be easier if the code resides in this repository. That being said, maintaining a date adapter for every date library out there is not really what I believe that the Angular team should put their limited time into.

[toamitc]

Any path forward on these adapters? Need to replace moment-adapter with luxon-adapter?

[MatthiasKunnen]

My proposal is for the Angular team to create a package to test new date adapters, e.g. @angular/date-adapter-tests. The major version of this package would be kept in sync with the version of @angular/material it supports. This package would then be used by the community-made date adapters. This ensures consistency between all the date adapters and when changes to DateAdapter occur, date adapter maintainers can pull the latest @angular/date-adapter-tests and simply run the tests to verify their implementation is still correct or requires work.

Another possibility is instead of a package, the angular team could create a repository that community date adapters could fork and apply patches from.

[mtpultz]

PR for LuxonDateAdapter that has been open for over a year: https://github.com/angular/components/pull/14681#issuecomment-745170191. Finishing off this PR and merging it in would buy time for discussions, debates, opinions, etc; while not perpetuating the use of Moment in new and current projects.