Replies: 8 comments 4 replies
|
To minimize the case for needing to extend or create our own, please consider the following
|
|
Yes, I'd like to see this as well. I can even imagine some of it could be improved even within the current version of DatePicker (but I understand priorities may lie elsewhere). For example, we are writing a new application where all localization of dates, times, numbers, etc. is done via Intl. The user selects their preferred language and we prepare Intl objects to format different data types. However, with DatePicker, unless I'm overlooking something, I cannot pass such instance to be used for formatting/parsing (nor can I pass a callback that would use it); there's just a |
|
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. |
|
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. |
|
Hey @sstrubberg, @tay1orjones, I just wanted to follow up on this as we鈥檙e currently doing some forward planning on our UI roadmap and are trying to make informed decisions around the DatePicker usage and investment. As mentioned above by Graham, we鈥檝e had to apply local patches to the current DatePicker to address accessibility gaps (such as for #11800) and meet customer requirements. It would be helpful for us to better understand the Carbon team鈥檚 current thinking on it's future direction. I completely understand that timelines are hard to commit to, but even a high-level signal on intent or priority would really help inform our planning. Thanks |
|
What is about the carbon web-components, are there also plans to update? |
|
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. |
|
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. |
|
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. |
|
Hi @tay1orjones, Just wondering if there has been any decision made yet on the future direction with respect to the Date Picker? I completely understand that timelines are hard to commit to, but even a high-level signal on intent or priority would really help inform our planning. Thanks |
|
We recently faced an issue where the date-range picker web component was throwing |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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:
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:
Compatibility
@carbon/reactand@carbon/web-componentsMigration
A migration path from v11 to v12 should be considered which has the potential to include:
All reactions