DateTimePicker - support light-date package (can replace moment)

[M-i-k-e-l]

Description

DateTimePicker - support light-date package (can replace moment)

I'v decided to allow support of the two libraries together in case someone has this use-case (that means we take moment as default but allow to override that default with the useLightDate prop).

I assume we'll delete the support for moment in v8.

Changelog

DateTimePicker - support light-date package (can replace moment)

[ethanshar]

I think that the advantage of using light-date is that we can install it as regular dependency (like lodash) and just use it.
If I remember correctly, users didn't want moment because it's a heavy dependency. We don't need to worry about it with light-date.

I would just swap the packages and use it directly instead of moment (and get rid of moment all together)

[M-i-k-e-l]

It's a problem because users (and us) will need to change the dateFormat`timeFormat` - you can see in the example screen it is very different; moreover it might give different results which will need UX approval.

[ethanshar]

Hmm I see your point. In that case, should we consider having a different API for the formatter?
maybe some sort of a function prop that formats the value? this way each can do whatever and we can set the default behavior (using moment or whatever) in private uilib. WDYT?

[M-i-k-e-l]

Not sure if that's what you meant but we can remove (deprecate) all four formatting props (dateFormat, timeFormat, dateFormatter, timeFormatter) and introduce a single one formatter here:

const getStringValue = () => {
  if (value) {
    if (formatter) {
      return formatter(value);
    }

This will eliminate any need for dependencies.
Unless you know why we should keep the two formatter types separated (the user knows what mode they're in).

[ethanshar]

But can you have a single formatter for all types of values? (date, time,...)?

[ethanshar]

Does DateTimePicker inherits all TextField props? You mean there's a name conflict?
Maybe call it dateTimeFormatter?

[M-i-k-e-l]

Yes, it extends it and passes them all.
I thought about it, I don't like it as much and was hoping you'll say that probably no one is using formatter :)

[ethanshar]

I guess no one does, but not sure I want to go into an adventure of name conflicts

[M-i-k-e-l]

ok, do we want to add a TODO to change to formatter in the next major version or not?

[ethanshar]

I think just leave it for now.. it's not crucial
Let's add the new prop and push this PR forward

[M-i-k-e-l]

Created #2625