Open Tropix126 opened 2 years ago
This also doesn't need to be a breaking change. The locale
prop could accept either an Intl
locale string, or a custom object like what's being used right now.
Sounds like a good idea, but I'm not sure if the weekday names would work. It seems you can only get M
or Mon
, but I think ideally we would have Mo
Sounds like a good idea, but I'm not sure if the weekday names would work. It seems you can only get
M
orMon
, but I think ideally we would haveMo
Hmm, yeah. This does seem to be consistent with how date-fns
handles locales. Do you know if this only an issue with english languages?
date-fns
supports all three, M
, Mo
and Mon
. I don't think it's anything specific to english
Could work to add a utility function for this for people who are fine with the weekdays being M
or Mon
(can be an option to choose between them)
The
Intl.DateTimeFormat
API has a few neat utilities for date-specific localization, including ones that can be used by this component to simplify locales. Additionally when a provided local is not specified/undefined
, it will automatically return data based on the user'snavigator.language
making it ideal for this sort of thing. It also means that there's no hardcoding or date formatting libraries required (I think).In this setup, the consumer of the library can simply provide a locale string and have the browser automatically output a localized array. It also means that if no locale is specified (through props, I guess) the datepicker will use the user's system language without any bundle overhead from a library like
date-fns
.