LocalizationProvider - Bring your own date management library

[devrnt]

Feature Request

Bring your own date management library: It's not a big deal to have multiple date libraries, I've read #198, but it becomes more "pleasant" and flexible to let the developer choose their own preferred date library. This can also potentially result in appealing to a wider audience.

Let's introduce a LocalizationProvider in mantine.dev!

Plan of Action

Shipping this feature would result in a breaking change, however, we are able to foresee a fallback (to the current dayjs library).

I'm heavily inspired by the approach of https://mui.com/ (no need to reinvent the wheel here).

1. Implement the LocationProvider which takes in a preffered date library adapter as prop, see adapters: https://github.com/dmtrKovalenko/date-io.
2. Migrate all the components that are dependent on the current date library (dayjs). Would mainly be the @mantine/dates components. These components will make use of the adapter api
3. Document everything

I've been doing some work already and I plan to continue working on this feature on condition that you green light.

Also awesome package, kudos!

[rtivital]

Hi @devrnt, thanks for proposal! I have not used date-io library, so can you please clarify how localization process would work with different libraries (let's take date-fns and dayjs as examples) – I'm most interested in locales tree shaking part since it is not obvious from date-io docs.

[vorant94]

does the current status of tc39 proposal for temporal (link) change anything on your decision here (maybe in the future when temporal becomes widely adopted standard)?

having an option to just drop all of date utility libs from the bundle sounds pretty intriguing to me even though i agree these libraries usually has very little footprint

[rtivital]

It is a proposal, not working yet, years before any significant browser support.

[vorant94]

yeah, i'm aware that it is still a proposal, but it is already stage 3 proposal, which means that the design is finished and most likely it is just a matter of time for becoming widely adopted by browsers

so in general my question more about if someone implements LocalizationProvider now or in the future before/after temporal becomes a standard, will it have a chance of merging into @mantine/dates or all the drawbacks you listed above still outweigh the benefit of such feature from your point of view?

[rtivital]

It is years before significant browser support, what's the point of discussing this now? Would it be any use for you if I say "Oh, yes, it is so cool, we would do that in 5 years"?

[vorant94]

since mantine is OSS anyone can decide to spend his/her spare time to implement feature they think will benefit the library. but every such change comes with a number of burdens:

• burden on contributor to implement it
• burden on maintainer to review and support it
• burden on other lib users to adapt it (if there are changes in public API or whatever)

while topic-starter or me or anybody else who wants this feature to be there can take the first burden on, the arguments you listed above appeal more to the second and third burdens. so even if feature is implemented without maintainers effort the PR can be declined due to those arguments and because of this risk it is questionable to even begin thinking about implementation

so the point of discussing it now is to just clarify whether this feature (if implemented by some volunteer contributor) has chance to be merged in the light of this proposal despite all the trade-offs you listed either now before temporal is widely adopted or when temporal becomes widely adopted. or it won't be merged even after temporal adoption because of backward compatibility or any other additional valid reasons

unless it is clarified nobody for sure won't take to work on it, once its clarified there is a possibility of someone taking it