Add ability to hide the IcDateInput control in the IcDatePicker

[dn55533]

Summary of the changes

Add ability to hide the IcDateInput control in the IcDatePicker

This allows the IcDatePicker component to be used as a more generic date picking calendar, without the added complexity of entering dates in the IcDateInput.

This makes the component more generic and allows the calendar and date picking part of the component to be used as a building block in other date-related components.

Related issue

N/A

Checklist

General

• Changes to docs package checked and committed.
• All acceptance criteria reviewed and met.

Testing

• Relevant unit tests and visual regression tests added.
• Visual testing against Figma component specification completed.
• Playground stories in React Storybook up to date, with any prop changes and additions addressed.
• Compare performance of modified components against develop using Performance addon in React Storybook.

Accessibility

• Accessibility Insights FastPass performed.
• A11y unit test added and yields no issues.
• A11y plug-in on Storybook yields no issues.
• Manual screen reader testing performed using NVDA and VoiceOver.
• Manual keyboard testing for keyboard controls and logical focus order.
• Correct roles used and ARIA attributes used correctly where required.
• Logical heading structure is maintained, and the HTML elements used for headings can be changed to fit within the wider page structure.

Resize/zoom behaviour

• Page can be zoomed to 400% with no loss of content.
• Screen magnifier used with no issues.
• Text resized to 200% with no loss of content.
• Text spacing increased as per the WCAG 1.4.12 success criterion with no loss of content.

System modes

• Browser setting 'prefers reduced motion' tested. No animations or motion visible whilst this setting is on.
• Windows High Contrast mode tested with no loss of content.
• System light and dark mode tested with no loss of content.
• Browser support tested (Chrome, Safari, Firefox and Edge).

Testing content extremes

• Min/max content examples tested with no loss of content or overflow.
• All prop combinations work without issue.
• Tested for FOUC (Flash of Unstyled Content) in both SSR (Server-Side Rendering) and SSG (Static Site Generation) settings.
• Controlled and uncontrolled input components tested.
• Props/slots can be updated after initial render.

[ad9242]

Hi @dn55533, thanks for the contribution. we will run it past the design team as the figma library may also require an update to match the behaviour.

Also would with the release of v3, would you mind carrying out this work in the v3.0.0/develop code base, as v2 will only be for major bug fixes soon. You are welcome to contribute it to v2 too, but just a heads up that the code bases are already slightly different, so may require some duplication of effort

[dn55533]

Hi @dn55533, thanks for the contribution. we will run it past the design team as the figma library may also require an update to match the behaviour.

Also would with the release of v3, would you mind carrying out this work in the v3.0.0/develop code base, as v2 will only be for major bug fixes soon. You are welcome to contribute it to v2 too, but just a heads up that the code bases are already slightly different, so may require some duplication of effort

Sure, happy to make the change in V3 as well. If you could review this V2 version, once you're happy with it I'll port it to V3.

[ad9242]

We're still wanting to run this past the design team, and it may take some time to get eyes on it, but we do have a few initial concerns. The date picker isn't currently intended to be used without the input field. The definition of it is: "A date picker is a type of drop-down control that allows people to easily view and select dates."

Our initial thoughts are that trying to just use the calendar view part might be better suited as a new component (which the date-picker could then potentially be refactored to use).

There are a few reasons for this:

• A number of props no longer make sense as they are passed straight through to the input control: helper text, label, validation messages, disabled & required are some quick ones that come to mind
• the accessibility of the datepicker & interaction with a screen reader currently requires the date-input as this is how the selected date is communicated to a screen reader

[dn55533]

Converted PR to draft to carry out the refactoring of the calendar into a separate component and refactoring of the date picker to use it.