Feat: Select Component

[simeonoff]

Closes #180

[rkaraivanov]

LGTM

Just some minor nitpicks

[rkaraivanov]

I guess you can throw in the group and header components as well

[rkaraivanov]

Since this is cancelable, do we want to move the focus when it is prevented? Maybe do it on igcClosed?

[simeonoff]

Setting this on the igcClosed event fires an extra focus event between the closing and the closed events.

[rkaraivanov]

Suggested change

	if (!event || !event.key || event.key.length > 1 || event.key === ' ') {
	// ignore longer keys ('Alt', 'ArrowDown', etc) AND spacebar (used of open/close)
	return;
	}
	// `/^\p{L}|\p{N}$/u` is even more pedantic
	if (!/^.$/u.test(event.key)) {
	return;
	}

[ChronosSF]

Testing notes:

1. Many options in storybook don't work if set through Storybook's UI
2. Spec needs a bit of love - autocomplete is listed as supported, but the prop is not available and probably doesn't make sense since select is not editable
3. Keyboard nav in the spec is not implemented the same way in the component
   • alt + left and right also open the dropdown, when in the spec only Alt + up/down should do it
   • left and right are supposed to navigate the items according to the spec but they don't (they do it while the list is closed but the spec doesn't seem to suggest they only work while the dropdown is closed)

Still to test: methods, events

[ChronosSF]

Changing the value resets the invalid state set through the API. It probably makes sense but it's better to have the behavior in the spec as well.

[ChronosSF]

Method observations:

• normalize the way return types are described in the spec
• navigateTo returns an igc-select-item, not value or index
• reportValidity returns boolean

[simeonoff]

Testing notes:

1. Many options in storybook don't work if set through Storybook's UI

2. Spec needs a bit of love - autocomplete is listed as supported, but the prop is not available and probably doesn't make sense since select is not editable

3. Keyboard nav in the spec is not implemented the same way in the component

   • alt + left and right also open the dropdown, when in the spec only Alt + up/down should do it
   • left and right are supposed to navigate the items according to the spec but they don't (they do it while the list is closed but the spec doesn't seem to suggest they only work while the dropdown is closed)

Still to test: methods, events

1. The options that don't do anything in storybook, unfortunately, are inherited from the dropdown component, but are not wired in storybook. We intend to not talk about those options in the documentation as these options should be obsolete in a future update when the dropdown component is refactored and the non-working options are made private and accessible only from the dropdown class.
2. Agreed.
3. To be updated.

[ChronosSF]

Ok, the other things I wanted to test look good, putting verified with the caveat that the spec needs to be updated to reflect the way navigation is implemented.

Let me know when you are ready with the thing you wanted to check regarding the input validity functionality and either merge it or let me know so I can.

[simeonoff]

Changing the value resets the invalid state set through the API. It probably makes sense but it's better to have the behavior in the spec as well.

The input component works the same way. Perhaps this requires further discussion but I think we should refactor all input-like components and their validity in another PR when we implement native form support for such elements.