Add date picker component

[ddaribo]

Closes #174

[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.

[damyanpetev]

This should ideally be localized :)
Perhaps, we can re-use the same string from the resource strings at least, seems like it'll make some sense.

[damyanpetev]

This is already the default title from the resource strings from what I can see, so passing this slot along... only disables the resource string handling? I think should be removed if so.

[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.

[damyanpetev]

The current state LGTM and covers the designs we need.
@rkaraivanov from the discussion for the toggle position, leaving to you if you want that to be logged separately so this can be merged.

[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.