Size Change: -30.1 kB (-2%)

Total Size: 1.21 MB

_{compressed-size-action}

mmmm! That's not bad.

(Ignore the style.css results—easy to save bytes if you have no styling lol.)

Thank you @noisysocks for attempting this! The bundle size savings are quite good, it'd be great to land these changes!

The CSS for react-calendar is actually pretty simple

Can we embed those styles by referencing them directly from the node_modules folder ?

Also, have we assessed that react-calendar is our best choice as of today?

We'd also have to test accessibility. Not sure what the differences there are.

We'd need to make sure:

• That the component still functions in the same way as it did previously, especially in terms of public APIs
• That the component is accessible (as you also mentioned)

Regarding the switch from moment to date-fns:

• I would look at replacing moment across all packages (not just the components package) — that is, @wordpress/block-library, @wordpress/components, @wordpress/date
• I would look at other alternatives too, before settling on date-fns (with particular interest for luxon or even just the recent native JavaScript APIs)
• We'd need to make sure that things keep working as expected, especially when dealing with timezones
• I would therefore apply these changes in a separate PR, decoupled from the calendar library swap

Agree with all your points! Regarding luxon, it's worth noting that react-calendar uses date-fns so if we decide on react-calendar then I think it makes sense to use date-fns as we'd already be bundling some of it anyway.

This was just a little Friday experiment and I don't really have the capacity to work on this right now. If there's a @wordpress/components contributor that wants to pick this up, feel free! Otherwise I can come back to this in a few months.

Can we embed those styles by referencing them directly from the node_modules folder ?

Yes, this works perfectly. The styles are so straightforward though that I think it might make sense to roll our own from scratch rather than import styles from react-calendar and then override half of them.

Also, have we assessed that react-calendar is our best choice as of today?

No, we should probably investigate some other libraries too. I was drawn to react-calendar because it looked very simple and lightweight but no doubt there are other good options 😀

Also, have we assessed that react-calendar is our best choice as of today?

I'd looked around for some options for this and I was most intrigued by https://github.com/its-danny/use-lilius. Being hook based it seemed like it would have all the flexibility we could ask for (besides making it quite lightweight).

Just chiming in to make sure folks are aware of the prior attempts to move to date-fns and the eventual revert due to some timezone-related issues:
#27550
If we want to pursue removing moment, it's worth looking more closely at Temporal as well, which is the proposed standard for this purpose and is polyfill-able:
https://tc39.es/proposal-temporal/docs/
It's a stage 3 proposal and not widely supported in browsers yet, though.

Looks like Chromium support for Temporal is under active development:
https://bugs.chromium.org/p/v8/issues/detail?id=11544
Thanks @sgomes for the pointer.

Gecko and WebKit seem to be working on it as well, after looking into this a bit more.

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1519167
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=223166

I'd like to add my support to @griffbrad's idea of using Temporal. The proposal is at stage 3, which means it's unlikely to see any major changes, so the API should be pretty final. This means the code we'd write now would likely work unchanged with what ends up shipping in browsers.

Using a polyfill for now means that in the worst case scenario we'd need to ship that for a while, and in the best case scenario we'd be able to get rid of it sooner than we expect. That's a strong advantage over a 3rd party library, which we'll always need to ship.

In addition, the Temporal spec is pretty extensive, and should cover pretty much every use-case, so functionality-wise I wouldn't expect it to be a problem.

That would leave the state of the existing polyfill as the only thing that still needs to be evaluated. The npm page claims it's still not production-ready, but it seems to be pretty far along in the roadmap, with only optimisation work left. Depending on the current state and our needs, it may actually be usable as-is.

https://github.com/its-danny/use-lilius

Neat!

I'd like to add my support to @griffbrad's idea of using Temporal. The proposal is at stage 3, which means it's unlikely to see any major changes, so the API should be pretty final. This means the code we'd write now would likely work unchanged with what ends up shipping in browsers.

Doesn't sound implausible that we could start using Temporal now or delay this refactor until Temporal is slightly more stable. It does rule out react-calendar and use-lilius though as both use date-fns. Maybe we could be the first to write a calendar component that uses Temporal!

I'm going to close this out as I don't really have the bandwidth to continue with the exploration right now. If you'd like to pick it up, feel free!