feat(input-date-picker, date-picker): improve date picking experience

[anveshmekala]

Related Issue: #3455

Summary

Update calcite-date-picker & calcite-input-date-picker UI & UX.

Key changes

• display two calendars for range irrespective of layout.
• No longer switches focus from day to end input when startDate is selected initially.
• Month selection is possible via select menu
• No longer positions the date-picker component relative to endInput when endInput is focused in range.
• Dates from previous months are not visible in range calendar.
• Divider indicator icons are removed in horizontal layout for range in input-date-picker.
• No longer uses chevron icon which indicate the open status of input-date-picker in startInput field.

Other issues resolved :
#6321
#6410
#10301
#10291
#10113
#10243
#10490
#10069
#9167

Wiki https://github.com/Esri/calcite-design-system/wiki/date%E2%80%90picker-enhancement-%238402

[macandcheese]

Is the intention that these are separate public components? Or all housed within one public component?

I know the native input can be type="month", but from my understanding, across other design systems, this approach seems (more?) common: https://mui.com/x/react-date-pickers/date-picker/#views

[anveshmekala]

Is the intention that these are separate public components? Or all housed within one public component?

I know the native input can be type="month", but from my understanding, across other design systems, this approach seems (more?) common: https://mui.com/x/react-date-pickers/date-picker/#views

Yeah, the idea is to have independent input-month-picker and input-date-picker components which makes it easier to maintain. Started off with month-picker though which can be used in input-month-picker and also integrated to current date-picker to allow user change month from a dropdown style.

Concurrently, I am testing a different approach to use combobox for input-month-picker and input-year-picker (similar to input-time-zone) which seems promising but wouldn't work if we need to display two scroll bars one for month and one for year.

I also dig the idea mentioned in the issue for input-month-picker which is more like a table with year at the top. It doesn't require two scroll bars.

[macandcheese]

Concurrently, I am testing a different approach to use combobox for input-month-picker and input-year-picker (similar to input-time-zone) which seems promising but wouldn't work if we need to display two scroll bars one for month and one for year.

IMO, this approach is just an implementation of a Combobox, a user can already set something like that up. I'd think ours would be more custom picking experiences like the examples linked in the original issue / Material example (however the components are structured).

I also dig the idea mentioned in the issue for input-month-picker which is more like a table with year at the top. It doesn't require two scroll bars.

Agreed, I think that's more appropriate for a component offering. If it's just a Combobox, we're only setting up an existing component with a set of pre-configured options, not providing a unique selection experience.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions.