aldabil21/react-scheduler

Support for date-fns v3

kraffi83 opened this issue · 4 comments

kraffi83 commented

Hello everyone,
When will date-fns v3 be supported?
Best regards

slash-84 commented

@aldabil21 what about making the lib agnostic from the adapter?

Since the lib heavily rely on mui we can try to use the same approach of Pickers and ask the developer to wrap on the preferred LocalizationProvider.

I understand it's a big change, I imagine all the format and date calculation functions should be revised under the same common interface used by mui.

aldabil21 commented

@slash-84 The breaking changes for v3 are the import strategy, no more default imports.
This component already uses named imports, so the changes needed to upgrade is just the adapter.

If its possible to not force the upgrade and can make it optional, I think would be awesome. Can you check #349 and adjust it to support the idea you mentioned?

aldabil21 commented

@slash-84
We can manage to support both v2/v3, however downside is:

  1. There will be a required prop dateAdapter to specify the adapter version (Since Mui team removed the export of /AdapterDateFns, we can't ddo internal optional version)
  2. The dateAdapter prop typing is any. Because the LocalizationProviderProps has changed to require 2 arguments LocalizationProviderProps<TDate, TLocale> in v3 instead of 1 argument LocalizationProviderProps<TDate> in previous versions. So the typing will fail

If you have better suggests, feel free to change PR #349 PR

slash-84 commented

I should investigate a bit more. At the moment is just a raw idea, we should do some experiment. For sure it will be a big change:

  • not using LocalizationProvider inside react-scheduler, but ask the developer to wrap it with the chosen one, like mui ask developers to wrap Pickers
  • not using date-fns at all and try to rely on the hook useLocalizationContext() in @mui/x-date-pickers/internals. It should have the necessary (🤞) to handle dates using an abstraction of the chosen date library.

In this way react-scheduler could become agnostic from both the locale and date adapted, giving the developer the possibility to chose from the ones offered by mui