Add date picker component

[ddaribo]

Closes #174

[AnjiManova]

Material

The "readOnly" and "nonEditable" properties are not working well for the Input in the Date Picker. I've checked the Input as a component, but the "readOnly" property works fine, so I think the problem might come from the Date Picker component. https://github.com/IgniteUI/igniteui-webcomponents/assets/127843837/978265b2-ae39-46ed-90d3-b80bfc35bc4c

Material, Fluent, Bootstrap and Indigo

1. An additional scroll should be added within the Dropdown, or at least the scrollable area should be the Dropdown, not the page itself. https://github.com/IgniteUI/igniteui-webcomponents/assets/127843837/ee180bfb-33da-42ab-bedb-9e2452c20a02

2. The fonts applied in the Dropdown based on the size component are correct, but when switched to the Dialog, the elements do not consume the fonts used (as a font style) in the Calendar.

Based on the component size, the font in "Large" should be Body 1, and for "Medium" and "Small," it should be Body 2 (all the dates, week numbers, days, abbr.)

These are the fonts used in the Dropdown, and they are correct Small Medium Large

These are the fonts used in the Dialog, and the font style is the same in all component sizes (16/28 Material -> Body 1; 16/22 Fluent -> Body 1; 16/24 Bootstrap -> Body 1; 13/18 Indigo -> Body 1). This should be fixed and aligned to the Calendar and the Dropdown variant in the Date Picker.

"Small" "Medium" "Large"

As you can see from the examples, the Dialog font is identical in all component sizes.

[ddaribo]

Material

The "readOnly" and "nonEditable" properties are not working well for the Input in the Date Picker. I've checked the Input as a component, but the "readOnly" property works fine, so I think the problem might come from the Date Picker component. https://github.com/IgniteUI/igniteui-webcomponents/assets/127843837/978265b2-ae39-46ed-90d3-b80bfc35bc4c

We logged a separate issue for this, as it can rather be addressed to the IgcDateTimeInput, which the date picker uses.

[imincheva]

The default toggle icon used in the Date Picker Input doesn't correspond to the one in the kit:

Implementation

UI kit:

[SisIvanova]

The default toggle icon used in the Date Picker Input doesn't correspond to the one in the kit:

Implementation

UI kit:

The icon is fixed here, but should also be updated in the Ignite UI Angular Date Picker.

[imincheva]

Arrows aren't working on the DateTimeInput. Please ignore this, if it's irrelevant to this PR.

https://github.com/IgniteUI/igniteui-webcomponents/assets/116892553/b15a2dc1-6bce-45b6-b64f-022c98ad3a51

[SisIvanova]

Arrows aren't working on the DateTimeInput. Please ignore this, if it's irrelevant to this PR.

Arrows_not_working.mov

I think this should be logged as a separate issue for the DateTimeInput.

[rkaraivanov]

Arrows aren't working on the DateTimeInput. Please ignore this, if it's irrelevant to this PR. Arrows_not_working.mov

I think this should be logged as a separate issue for the DateTimeInput.

It is a sample issue in the Storybook for the auto generated docs page. The actual sample works so if you log it add a storybook/samples tag as it is not the component itself.

[AnjiManova]

Material, Fluent, Bootstrap and Indigo

1. An additional scroll should be added within the Dropdown, or at least the scrollable area should be the Dropdown, not the page itself.

In addition to this point, we agreed that the optimal solution would be to set the Dropdown max width to 2 calendar widths and add a scroll when more than 2 calendars are displayed.

Everything else looks good and implemented.

[AnjiManova]

@SisIvanova already fixed the scrollable issue in the Dropdown and I believe we are all good with the Date Picker component validation. All comments are implemented or logged as separate issues.

[kdinev]

@ddaribo @AnjiManova I went through the specification and the designs and I see the design handoff covers the date picker drop down and the date picker dialog. However, I'm unable to find neither in the specification, nor in the design, what action on the input, apart from alt+arrow down are supposed to trigger the opening of the picker in the different modes. The differences that I currently see:

• dialog mode
  • angular: opens the dialog on input focus
  • web components: opens the dialog on date picker icon click (input prefix)

@ddaribo Also, I don't see any change events ever being emitted in the default storybook example.

[ddaribo]

@kdinev I double checked the initial Spec meeting, where it was discussed that the Angular’s ‘dialog’ mode input not being editable is a bit restrictive and can be subject to refactoring in the future. As for the WC Date picker, the nonEditable property is introduced, so that it can be configured to support all combinations of ‘dropdown’/’dialog’ mode and editable/non-editable input. So, since the ‘dialog’ mode allows editing the input in WC, opening the dialog on input focus would be disruptive. This leaves the “Alt + Arrow Down/Up” and the calendar icon click as the ways to open the picker in both modes. I guess if I am missing something @rkaraivanov could chime in. @AnjiManova as well.

Indeed the spec does not really mention the calendar icon click opening the calendar picker for both modes. Please, let me know, if you still think the spec should be updated to describe this more clearly.

[rkaraivanov]

FYI, component events are automatically listened on by our storybook setup by default 😃.

[kdinev]

@kdinev I double checked the initial Spec meeting, where it was discussed that the Angular’s ‘dialog’ mode input not being editable is a bit restrictive and can be subject to refactoring in the future. As for the WC Date picker, the nonEditable property is introduced, so that it can be configured to support all combinations of ‘dropdown’/’dialog’ mode and editable/non-editable input. So, since the ‘dialog’ mode allows editing the input in WC, opening the dialog on input focus would be disruptive. This leaves the “Alt + Arrow Down/Up” and the calendar icon click as the ways to open the picker in both modes. I guess if I am missing something @rkaraivanov could chime in. @AnjiManova as well.

Indeed the spec does not really mention the calendar icon click opening the calendar picker for both modes. Please, let me know, if you still think the spec should be updated to describe this more clearly.

I tried the non-editable input and the behavior is still different from angular. The primary usage of the dialog mode for date picker is mobile devices and there the expected behavior, I believe, is the one that we have in Angular. We already have a date editor, a date picker with drop-down mode, which all can be used as editors. The dialog mode is a pure "picker" mode, IMO. The design team should also take a look at this.

[kdinev]

FYI, component events are automatically listened on by our storybook setup by default 😃.

Maybe something was wrong while I was running this. I really wasn't seeing any change events there.

[kdinev]

@AnjiManova I found the piece about the end-user experience in the date picker specification in Angular. https://github.com/IgniteUI/igniteui-angular/wiki/Date-Picker-Specification#3-functionality

Can you confirm the behavior?

[AnjiManova]

@kdinev, we confirm the behaviour described in the specs: "In dialog mode, the input will always be read-only, and clicking anywhere on it will open the dialog."

[rkaraivanov]

@AnjiManova @kdinev The specification is updated, and the behaviors are implanted with the last commit in the PR.

[damyanpetev]

@AnjiManova Is it me or the Design Handoff in the spec only deals with the actual calendar popup but nothing on the input or component as a whole. I realize it's mostly the same as any Input with a built-in calendar toggle and clear, but still at least one detail I think we might've missed: In Angular at least we've explicitly allowed the toggle to be overridden and move from start to end (as a suffix). We've used that in the old Input landing demo (https://www.infragistics.com/angular-demos/data-entries/input-group-sample-6, not really live anymore) and in two other form samples https://www.infragistics.com/products/ignite-ui-angular/angular/components/input-group#typed-forms https://www.infragistics.com/products/ignite-ui-angular/angular/components/angular-reactive-form-validation#angular-reactive-form-validation-example Just wondering how important it is to be able to align all picker-like components like that and if that's something we should consider. On the technical side that might spell a change to how we slot the current calendar-icon and shuffle the hardcoded prefix to that as well so the user can change it.

[AnjiManova]

@AnjiManova Is it me or the Design Handoff in the spec only deals with the actual calendar popup but nothing on the input or component as a whole. I realize it's mostly the same as any Input with a built-in calendar toggle and clear, but still at least one detail I think we might've missed: In Angular at least we've explicitly allowed the toggle to be overridden and move from start to end (as a suffix). We've used that in the old Input landing demo (https://www.infragistics.com/angular-demos/data-entries/input-group-sample-6, not really live anymore) and in two other form samples https://www.infragistics.com/products/ignite-ui-angular/angular/components/input-group#typed-forms https://www.infragistics.com/products/ignite-ui-angular/angular/components/angular-reactive-form-validation#angular-reactive-form-validation-example Just wondering how important it is to be able to align all picker-like components like that and if that's something we should consider. On the technical side that might spell a change to how we slot the current calendar-icon and shuffle the hardcoded prefix to that as well so the user can change it.

@damyanpetev, no, it's not you; in the handoff, the main focus was on the popup, and yes, you are right - the date picker compound parts are the popup and the input with a built-in toggle and clear icon.

Unfortunately, we don't have visual examples for the input, which we should update and provide to make it clearer.

Regarding your question, the variants provided in the kit currently start with a toggle because in AB, the default and only view of the component is with a toggle at the start. This is why we assumed that we are going to cover only one toggle position for the component for now. If there is a way to expose a property for the toggle icon in AB where you can select the toggle position, we will add such a variant in our Figma kits. In addition, if we want the default position of the toggle to be at the end, that should also be changed in AB.

In terms of your question whether there is a need to have the start and end positions of the toggle icon, IMO, yes, the current behaviour of the component you have described (allowed the toggle to be overridden and move from start to end) should stay the same, and we could consider supporting the two options (again AB should replicate the kits variants and after that we will make the change).

[damyanpetev]

[...]

@damyanpetev, no, it's not you; in the handoff, the main focus was on the popup, and yes, you are right - the date picker compound parts are the popup and the input with a built-in toggle and clear icon.

Unfortunately, we don't have visual examples for the input, which we should update and provide to make it clearer.

Regarding your question, the variants provided in the kit currently start with a toggle because in AB, the default and only view of the component is with a toggle at the start. This is why we assumed that we are going to cover only one toggle position for the component for now. If there is a way to expose a property for the toggle icon in AB where you can select the toggle position, we will add such a variant in our Figma kits. In addition, if we want the default position of the toggle to be at the end, that should also be changed in AB.

In terms of your question whether there is a need to have the start and end positions of the toggle icon, IMO, yes, the current behaviour of the component you have described (allowed the toggle to be overridden and move from start to end) should stay the same, and we could consider supporting the two options (again AB should replicate the kits variants and after that we will make the change).

@AnjiManova 👍 Certainly not asking for changing the default for the date picker in the design system (would affect Angular too). Also not necessarily needed for the UI Kits & AB to include that option (I still consider those only a reasonable subset of the component design/capabilities) - at least not until we implement it here and we decide it's useful to expose. So merely interested if there's are use cases for such option and if we should implement it in the control which seems to be the case.

[rkaraivanov]

@damyanpetev

Yeah, this would be a nice feature for components that have a toggle action part. Of the top my head I would say the date-picker, combo and select components all fit this category. Anyways, I don't want more feature creep for this PR so this should definitely be its own task in the repository.

@AnjiManova I suppose you can go over the components that ought to support the described behavior and come up with designs so that we can start thinking of the actual implementation in terms of code.