Improvement suggestion: replace react-dates with smaller library

[sgomes]

Is your feature request related to a problem? Please describe.
react-dates is the single largest contributor to Gutenberg components bundle size, coming in at 184KB of JS, or 36KB over the wire.

It is used for a single component, the DatePicker (components/src/date-time/date).

As a comparison, the 184KB it pulls in is more than jquery and lodash combined, which seems excessive for enabling a single component.

Describe the solution you'd like
Replace usage of react-dates with a smaller library, or alternatively implement a date picker from scratch.

Alternatives include react-datepicker (70KB uncompressed, 16KB over the wire) and react-day-picker (38KB uncompressed, 8.3KB over the wire, used in Calypso).

Taking Calypso's full client/components/date-picker components as a starting point to develop a new package, which could be shared by Calypso and Gutenberg, may also be a good option.

I'm happy to take on some or all of this work myself if there's agreement on a good solution.

Describe alternatives you've considered
Lazily loading the library when the date picker is first needed may be an option as well, although I believe that would require adding a new chunk specifically for that purpose. It would mitigate the issue, by delaying the JS loading until the date picker is actually needed and thus making Gutenberg components load faster. It's not an ideal solution, however, as it doesn't get rid of the excess JS.

[gziolo]

Some context, react-dates was added in #7621 to resolve some accessibility issues. We need to ensure that by replacing it with alternative solution we don’t regress from the accessibility standpoint. An alternative would be to contribute to the library or fork it and optimize ourselves.

In the past we forked react-color in #10564 but it was tons of work.

[sgomes]

#21914 partially fixed this issue, by removing a good chunk of the imported react-dates. It turns out that the library doesn't tree-shake correctly, so there was more being pulled in than what Gutenberg was making use of.

The numbers now stand at ~95KB uncompressed (roughly half of what it was before #21914), or 20KB over the wire. That is still larger than the alternatives, but the a11y tradeoff may be worth it. Further investigation is likely needed.

[aduth]

I think it's worth exploring the idea of asynchronous loading. The specific interaction of setting a scheduled date of a post is one which I suspect would only constitute a small fraction of most editor sessions. Or at least it seems to be one which would be fine to defer to the time at which the interaction is made, since the date selection occurs in a separate context (the popover) which doesn't need to be rendered until the time at which the user makes an explicit choice to set that date. We can also optimize this further by inferring intention to assign a date from mouseover or focus on the date button (similar to InstantClick).

I do expect there would be some non-trivial challenge here in getting it to interoperate with Webpack and WordPress's script loader, though I do think this could prove useful for a variety of use-cases beyond just this one example.

[retrofox]

Some context, react-dates was added in #7621 to resolve some accessibility issues.

Correct. However, it's like the cake turned again. react-datepicker supports a11y pretty well now. and the last commit of react-dates was in Nov 2019. We've been testing on #25428, and it looks good.

[simison]

Work on this seems to have stalled — @sgomes @retrofox any thoughts on continuing or should we somehow signal that this needs contributors? (e.g. at the weekly meeting)

[sgomes]

I think it's still definitely worth looking into this, regardless of whether the calendar eventually gets lazily loaded, which was also suggested. The tree-shaking fix I put together in #21914 helped, but this is still far too large for how little use it gets.

[retrofox]

Work on this seems to have stalled — @sgomes @retrofox any thoughts on continuing or should we somehow signal that this needs contributors? (e.g. at the weekly meeting)

It's still part of our remaining tasks but It was specifically assigned to nobody yet if I'm not wrong. We talked a little about this issue with @pablinos and AFIAK we probably won't take over this in the next few days. I'd be happy to take it, though
:nod: and we are going to dig on this.

The tougher issue here for us is how to make progress and deliver quick solutions progressively. We're going to review what we did and try to get a development plan.

[mtias]

Curious how close we might be to switch entirely to <input type="date" />. There are some polyfills like: https://brianblakely.github.io/nodep-date-input-polyfill/

[retrofox]

Looks exciting.

Using the native implementation with a fallback sounds promising.

[sgomes]

Curious how close we might be to switch entirely to <input type="date" />. There are some polyfills like: https://brianblakely.github.io/nodep-date-input-polyfill/

That is the best possible approach, if we deem the native input to be sufficient 👍
Polyfills can be dropped over time, and even while they're still around they could be part of a differential loading strategy (different builds for different browsers), if Gutenberg decides to implement one.

[Mamaduka]

The library was removed in #43005.