feat: Dayjs localizer

[marnixhoh]

Notes:

• I based the dayjs localizer off of the one for moment, as their API's are very similar
• Note that when setting a default timezone on dayjs, this is only used when instantiating a dayjs instance by calling dayjs.tz(). Hence, it is manually checked whether a timezone aware dayjs should be used or not.
• moment inverts offsets to be POSIX compatible. Dayjs doesn't do this, so I manually inverted them. moment docs
• moment(date1).isSame(date2, 'date') is equivalent to moment(date1).isSame(date2, 'day'). see: note at https://momentjs.com/docs/#/manipulating/start-of/

I tested the dayjs localizer in the storybook, and everything seems to be working fine

Fixes #1953

[marnixhoh]

@cutterbl Are you able to provide a time estimate as to when this will be reviewed/merged?

Thank you so much :)

[cutterbl]

@marnixhoh Finally getting an opportunity to look through this. Here are a few notes.

• The final paragraphs of the Localizers Guide need to be updated to include the new localizer.
• The localizer prop documentation needs to be updated to include the new localizer
• Looking at the demo example code, if the localizer requires all of these plugins to extend dayjs to function properly (isBetween, isSameOrAfter, etc) then extending dayjs should automatically happen at the beginning of your dayjsLocalizer function rather than having the developer figure it out. The only real exception to that is if you're allowing the developer to optionally including timezone support. (See the momentLocalizer for clarity on optional tz support)
• When constructing date based props for you Calendar demo, try to use the library (dayJs) to construct those prop values (something we need to fix in some demos), as opposed to the dates utils.
• If you review the unit tests you'll see commented out bits for the Luxon localizer. These are currently used to quickly switch out the localizer used in testing. Please provide configurations for the DayJs localizer as well, so that testing can be verified.

[marnixhoh]

@cutterbl Thank you for your feedback and comments! :)

I have one question on your 3rd point. The date-fns example on the README.md also makes the user set up the necessary plugins themselves. Imo doing it this way feels "right" as now no dayjs imports are needed in the localizer file itself. Otherwise, what's the point of not just importing the library itself in the localizer file as opposed to making the user supply it to the exported function?

Let me know your thoughts and how you would like me to proceed.

Thanks and have a good weekend!

[cutterbl]

@marnixhoh You bring a valid point. That particular piece of documentation goes back quite a ways, since before we began using the localizers (internally) for managing internal date math. We're currently in discussions around Big Calendar vX, where we are talking about having the localizers as their own separate packages. For now though, I'll stick with my thoughts on bullet three though. If we require this functionality internally to properly manage calendar display, then it really should be part of the default configuration, and the developer shouldn't have to guess at it.

[marnixhoh]

@cutterbl Thank you for that explanation.

I have implemented all points you mentioned. Please let me know if anything else is needed to get this merged.

Thanks again for your help and feedback :)

[cutterbl]

This is close. Don't import dayjs in the localizer and extend(). Apply the extensions to the instance of dayjs that they pass into the localizer function itself, right before you apply the locale. In the documentation for this localizer you'll want to let the developer know that these extensions will be applied, so they don't add them themselves, but this allows the developer to add other extensions that they feel may be needed by their app as well.

[marnixhoh]

@cutterbl Thanks for your feedback! I have just fixed that and added this change to the docs.

The reason I initially extended dayjs with the plugins outside of the localizer, is because these plugins are applied globally to all dayjs instances. So functionally, it doesn't really matter where these plugins are loaded.

Please let me know if there is anything else that needs to be done! :)

[marnixhoh]

Hi @cutterbl! I was wondering if you've had a chance yet to look at my most recent commits to this PR?

I can only imagine how busy you are - the last thing I want to be is pushy. I'm just very excited for this PR to get merged!

Thanks :)

[cutterbl]

@marnixhoh Sorry, I've been selling my house and moving from one state to another. Still buried in boxes. I will take another look soon, just give me a little time.

[marnixhoh]

@cutterbl No problem at all! I can imagine how stressful that must be. Take your time and good luck :)

[dejankortechs]

@cutterbl hey, thank you for this library.

Will this one be merged soon?

[ikraamdaanis]

When will this pull request be merged? In our repo we use Dayjs because it has a small bundle size.

[marnixhoh]

@dejankortechs & @IbnDaanis I hope soon! 🚀

@cutterbl I hope the moving is going well. :) When do you think you'll be able to review the PR? Thank you so much

[jogri]

Thanks @cutterbl for this dayjs localizer. Hope to see this soon in the master branch!