Refactor date picker to make components reusable for date range picker

[kangzj]

What?

The PR refactors Calendar and Day to separate components, so that they could be used in the to-be-created Date Range picker. The prototype could be found here.

Why?

Create a Date Range picker as a Core component.

How?

Extracted Day and Calendar to separate component, and re-arranged event handlers.

Testing Instructions

• Ensure all tests pass
• Open storybook and find DatePicker
• Ensure all the examples still work okay
• Ensure the code looks okay

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @kangzj! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: kangzj <[email protected]>
Co-authored-by: mirka <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[mirka]

Hi, thank you for contributing 👋 Linking to the main issue so we can track related progress: #60971

Before we make code changes, do we have alignment with @WordPress/gutenberg-design on what we're aiming for? To start, your prototype already deviates from an initial design that was proposed, which was two DatePickers linked together (yours seems to be done with a single DatePicker). Furthermore, we are starting to consider even leveraging <input type="datetime-local"> for its various benefits (#64390).

[kangzj]

Thanks for the feedback @mirka.

Before we make code changes, do we have alignment with @WordPress/gutenberg-design on what we're aiming for?

Sorry I'm not aware of the process. We are aiming for part of the design in #60971. To be specific, our scope for the project is only the date range picker, without any of the inputs, shortcuts or apply/cancel buttons, just like the following.

To start, your prototype already deviates from an initial design that was proposed, which was two DatePickers linked together (yours seems to be done with a single DatePicker)

Like mentioned above, we are committed to create the date range picker. The prototype is only a start, and no design has been applied yet. I'm working towards implementing the functionality first and applying the design after. This will be an incremental process. Also I don't want the prototype to grow any bigger before I start merging to Gutenberg since we can mark components WIP. However, if the team prefers it finished and merged as a whole, I would be happy as well.

Furthermore, we are starting to consider even leveraging for its various benefits (#64390).

This is one of the reasons I wanted to share my approach earlier rather than later. I shared in slack as well - this is the approach we think that doesn't satisfy our needs, meaning we don't think it's the easiest way to picker a date range.

Please let me know if I should pause the work till the agreement is reached; otherwise I'll move forward. Thanks all.

@keoshi @ederrengifo @emaurer11 @tyxla @jameskoster @oskosk

[kangzj]

I spent some time today to make the prototype look more like the design, but still a WIP:

Screen.Recording.2024-09-05.at.4.30.27.PM.mov

[mirka]

Like mentioned above, we are committed to create the date range picker. The prototype is only a start, and no design has been applied yet. I'm working towards implementing the functionality first and applying the design after. This will be an incremental process.

That's totally fine, and once we do reach agreement on the high-level design, it's not unlikely that the dev work will start with some refactoring work like you are doing here and then continue as an iterative process.

For highest efficiency, I believe the process here will need to be:

1. Align with @WordPress/gutenberg-core on design specs.
2. Align with @WordPress/gutenberg-components on overall API/modularity design.
3. Iterative dev work (thank you again for contributing on this front 🙏)

After step 1 is complete, we'd also appreciate your participation in step 2 to make sure we're covering all the necessary use cases.