DatePicker v12 📅

[dakahn]

Carbon v12 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
• ???

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