DatePicker Next 📅

[dakahn]

The NEXT Carbon DatePicker will be a from-the-ground-up refactor of the existing component that should take into account the following:

Dev

The primary motivation for the refactor is dropping the Flatpickr dependency improving DX, extensibility, and lowering maintenance cost for the component. Which leaves us with a few options in how to move forward (ordered naively in terms of difficulty):

• utilize a modern React date picker with relatively analogous APIs and functionality:

  • DatePicker - React Spectrum
  • Airbnb React-Dates
  • Deque Cauldron Datepicker
  • Duet Design System DatePicker

• utilize a DatePicker primitive as a base to build on top of:

  • useDatePicker - React Aria
  • Date Picker Dialog Example WAI-ARIA

  This is arguably simpler than the previous option because there's less potential for conflict with existing CSS class names/styling

• Use browser native <input type="date">
  All modern browsers have a built in implementation of a table calendar the user can select dates from. How different/alike they are in functionality and build is an unknown

• Build a wholly bespoke custom implementation

• ???

Design

• the previous DatePicker design/UX was limited by the aforementioned Flatpickr dependency. With that dependency gone, we can evaluate if we want to revisit those designs or improve the existing UX
• product teams that are extending functionality can potentially have that functionality included out of the box with v12 DatePicker lifting up maintenance/support cost to the Carbon team
• ???

Acessibility

It goes without saying that the v12 Carbon DatePicker should be designed/built with 100% WCAG AA level accessibility out of the box. We should lean on industry leaders in the accessibility space internal and external in that regard. Here are some relevant links:

• Date and Time Pickers for All - Adobe
• Collecting Dates in an accessible way - Hassell Inclusion
• Gov.uk design system Dates component discussion
• WC3 Datepickers docs
• A New Day: Making a Better Calendar - 24 Accessibility
• ???

Compatibility

• The route we choose should be framework agnostic and able to be used within @carbon/react and @carbon/web-components

Migration

A migration path from v11 to v12 should be considered which has the potential to include:

• an EXPERIMENTAL__DatePicker version we can test with Carbon users
• API mappings for previous props
• codemods for projects looking to update
• outreach to teams using and extending v11 DatePicker
• ???

[stuckless]

To minimize the case for needing to extend or create our own, please consider the following

1. if the component is going to display a date or allow the date to be entered from a keyboard it should expose parse/format function properties to allow teams to provide their own parsing/formatting of the date.
2. if the component is going to validate a date it would provide the ability to provide a custom validation function
3. Allow for custom placeholder text

[grahamharper]

Are there any more updates regarding plans for a new date picker?

The current one has so many issues, particularly accessibility issues. My team has applied a lot of customisations in a wrapper component to plug the holes but it's increasingly difficult and maintenance is very hard.

[sstrubberg]

hey @grahamharper thanks for reaching out. Unfortunately, no plans in the immediate future, but I appreciate you bringing it it up. The ol' datepicker is starting to show it's age and we'll need to address it soon.

[tay1orjones]

• https://github.com/gpbl/react-day-picker
• https://github.com/Hacker0x01/react-datepicker

[boeckMt]

What is about the carbon web-components, are there also plans to update?

[sstrubberg]

As it stands today and for the foreseeable future, any work we take on, and this includes future DatePicker work, we would be build for both React and Web Components.

[tay1orjones]

One additional requirement that would be nice to have as part of this is multiple calendar support, #7265. This was recently brought up again internally.

[tay1orjones]

Another nice to have would be combining datepicker and timepicker, #10186. Probably not to actually merge the components (we could, I just don't think it's necessary?), but we could integrate them together more intentionally through composability.