RFC: Make DatePicker/TimePicker/Calendar date-library-agnostic

[yesmeck]

Previous discussions #5677, ant-design/ant-design-mobile#1217.

Motivation

moment do have some downsides like it's mutable value and un-modular. And it's road to modular seems very slow. I also found that the moment team is writing another date library called luxon. It would be a big improvement if we can make our date related components date-library-agnostic.

Detailed design

Create a rc-date-util package. It only contains one line:

export default from 'rc-moment-adapter';

rc-moment-adapter wraps all APIs which date components used.

All date related components use rc-date-util instead of using moment directly.

People can change date library through webpack's alias:

// webpack.config.js

module.exports = {
  resolve: {
    alias: {
      'rc-date-util': 'rc-date-fns-adapter',
    }
  }
}

Browserify users can use aliasify:

{
  "aliasify": {
    "aliases": {
       "rc-date-util": "rc-date-fns-adapter",
    }
  }
}

After aliasing rc-moment-adapter to rc-date-fns-adapter, all dates pass to callbacks should change to native date object as well.

const onChange = (date)  => {
  console.log(date); // Native date object.
}

<DatePicker onChange={onChange} />

This change won't effects any users who don't want to change moment to other date library.

Drawbacks

Rely on build tool config.

[andriijas]

WIll the adapters be small in size? another concern with moment related to unmodular is the huge size. What are the most common operations on time and date in antd that brings in the need for a library? can we detect those and see if its better to have adapters or just write our own antd date helpers? i guess we dont want to maintain own code managing dates but if the result is less code than adapters it should be considered.

[yutingzhao1991]

const onChange = (date)  => {
  console.log(date); // Native date object.
}

Should date keep to use moment or other date library?

We can add a common method in rc-[xxx]-adapter like parseFromNativeDate for this.

[yesmeck]

The adapter should be very small. I don't think we will repalce moment with our own date helper, because we don't want break any exists code, but we can have a antd-vanilla-date-adapter or something whatever name which don't reply on any date library.

[yesmeck]

Should date keep to use moment or other date library?

date type changes only if rc-date-util is replaced with other adapter.

[andriijas]

Sounds great, thanks for making moment opt-in! Appreciate it!

[hlehmann]

I really like this feature, any update on this ?

[otakustay]

Depending on build tools to implement type adapters is not a good solution, why don't we just make dateUtil as a prop of date pickers with a defaultProps value as official rc-date-utils

[afc163]

#10437 is a better proposal

[hk-ng]

#10437 is closed. Should we reconsider date-library-agnostic solution here?

[maxcan]

Strong proponent of luxon. Its combines moment clean, easy to use API with the immutability of date-fns.

there is at least one abstraction library available which may make this easier: https://github.com/dmtrKovalenko/date-io