-
Notifications
You must be signed in to change notification settings - Fork 2.1k
DatePicker v12 📅 #11967
Copy link
Copy link
Closed
Labels
component: date-pickerplanning: umbrellaUmbrella issues, surfaced in Projects viewsUmbrella issues, surfaced in Projects viewsproposal: acceptedThis request has gone through triaging and we are accepting PR's against it.This request has gone through triaging and we are accepting PR's against it.role: design ✏️role: dev 🤖type: enhancement 💡version: 12Issues pertaining to a future major release of CarbonIssues pertaining to a future major release of Carbon
Metadata
Metadata
Assignees
Labels
component: date-pickerplanning: umbrellaUmbrella issues, surfaced in Projects viewsUmbrella issues, surfaced in Projects viewsproposal: acceptedThis request has gone through triaging and we are accepting PR's against it.This request has gone through triaging and we are accepting PR's against it.role: design ✏️role: dev 🤖type: enhancement 💡version: 12Issues pertaining to a future major release of CarbonIssues pertaining to a future major release of Carbon
Type
Projects
Status
Completed 🚢
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:
utilize a DatePicker primitive as a base to build on top of:
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
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:
Migration
A migration path from v11 to v12 should be considered which has the potential to include: