Component: Date ranger picker

Description

To select a date range in the product today, we leverage a 2 date picker components. Using a set of From and To drop-downs.

To add a set of predefined date ranges, we current add an additional dropdown. This adds yet another element to a usually already busy page, adding to the cognitive load of the page.

Ideally there would be a single component which handles date filtering.

Current state	Proposed future state

Additional design considerations:

~4 months ago the following MR (Add basic support for issue filter by date (gitlab-org/gitlab!120160 - merged)) introduced the ability to filter issue by date using the filter bar.

Date filtering via filter bar

Adding another place to filter date/time creates confusion and adds complexity.

We should consider moving all date/time filtering to a single component.

Date filtering via Date range picker

Depending on the output of the following UXR [UXR] Understand user needs around date range s... (gitlab-org/gitlab#415502), the Date ranger picker could support predefined ranges like milestones and iterations.

Designs

• ❖ Figma branch →
• Figma component issue: Figma > Date ranger picker - add to Pajamas (#1704 - closed)
• See Design management for specs and states.

Resources:

• This new date ranger picker component proposal was motivated by the following issue: VSA: [UX] Usability improvements - adding prede... (gitlab-org/gitlab#408656 - closed)
• Related issue from 3 years ago: Component: Date range picker (#601 - closed)
• https://designsystem.digital.gov/components/date-range-picker/
• https://codyhouse.co/ds/components/app/date-range

Checklist

Make sure the following are completed before closing the issue:

1. Assign the correct component label to this issue.
2. Create an MR with the additions or updates needed.
3. When applicable, create an issue using the Figma update issue template to update the component in Figma, and mark it as related to this one. Bring the issue to your team planning session for prioritization and scheduling.
4. When applicable, create an MR in GitLab UI to update the component. If you do not have capacity or are unable to update the component directly, create a GitLab UI issue using the Component issue template. Mark the new issue as related to this one. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
5. When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
6. 🎉 Congrats, you made it! You can now close this issue.