Igniteui-angular: igx-select should allow typing

[grosch]

It would be nice if the igx-select let me start typing and it did a 'contains' search against the list. When the list is huge, it's much easier to type part of the text you know exists.

[SlavUI]

@grosch did you check the Autocomplete control for this functionality :https://www.infragistics.com/products/ignite-ui-angular/angular/components/autocomplete.html

[grosch]

I just saw that myself and will look into it. I don't know why Infragistics is making this so hard though. Now we have the multiselect dropdown which does EXACTLY what is desired, but it forces multi-select. Then we have the new IgxSelect which does single select, but doesn't allow any typing. And then we have a dropdown with the autocomplete as well. Four separate controls to use that all basically do the same thing, just slightly different variations.

[Eralmidia]

I have to second @grosch on this one. I have been thinking the same thing when it comes to select/combo like controls. I always have to go to the docs to separate which controls have which features. It seems to me that all of these should have been a single control, with a lot of customization options.

[kdinev]

@grosch @Eralmidia The IgxSelect is a mimicking the native <select> behavior as closely as possible, and you can, in fact, input key stokes and the list will be searched for the matching value and it would get focused. You can test this in any of the samples:

https://www.infragistics.com/products/ignite-ui-angular/angular/components/select.html

Input ba and you will see Banana being focused.

If you need to use larger lists, then as @SlavUI suggested, an auto-complete is probably a better choice for component.

To answer the question about separating these functionalities into separate components.

1. These components are different and serve a different purpose.

   • Drop down - a menu like drop down UI from a target. Most common use-case is navigation.
   • Select - native select-like form component for picking a single value from a finite and relatively small list. Best use-case is when you have up to 50 different preset values that the user can pick from.
   • Auto-complete - form values list attached to an input field. Suggestions are presented upon certain input and selection is performed, or value that is not present in the list is being submitted. Most common use-case is when your end-user is aware of what their input should be, but you already have a relatively large prepopulated list of values. Example would be a City input in an address form. Good for lists that contain over 50 unique values, as such lists require lots of scrolling and it's better to populate the DOM dynamically.
   • Combo - advanced form multi-selection component for very large lists that are multiple-choice. Have advanced features like list filtering due to it being for hundreds or even thousands of different unique records. The list's DOM is thus virtualized. A sample use case would be a form for parts ordering, where there's hundreds or even thousands of different parts the user can choose from, and can order one or more than one different type.

2. Separation of logic ensures stable components. Single multi-purpose component for all of the use cases mentioned above, and others, will result in a large code base with a multitude of code branches for different use-cases, which eventually makes the component very unstable. A fix for the select use case, for example, can potentially impact all the rest of the use cases undesirably.

3. Use-case specific UX, instead of a single multi-purpose UX. If this was all one component, then it would have one and the same DOM structure and single behavior, with workarounds for multiple use-cases. You may want an input, while other users wouldn't want one. The input would still be there and there will be a workaround in place that hides it, or disables it, etc. for other users. This results in suboptimal UX for different use-cases.

4. Separation of components for the different use-cases creates optimal package size for the developer. If all the use-cases were packed into a single component, then whenever you're building your application, your package would contain the code of all, regardless of how many of them your application actually serves. Example - you have a select in a single form - the application build will include the code for the combo and auto-complete use-cases as well. This holds true for the themes as well. Currently, if only select is used, then only the IgxSelectModule and the select theme are being bundled.

I know that, at first glance, it may seem that we're making this "hard", but in fact we've made these decisions based on years of experience with other products that we've delivered. The approach that is suggested was in fact the approach taken with the Ignite UI for JavaScript, our jQuery product, and all the negatives of this approach, some of which I've mentioned above, were actually felt by our users and we never ended up having a single multi-purpose combo component that served the use-cases it was intended for 100%.

[Eralmidia]

@kdinev Good points. I concur. I guess it more a matter getting used to the different choices. For me the confusion at first was really the difference between a combo and a drop down. But looking at the drop down as more of a menu, like discussed in https://github.com/IgniteUI/igniteui-angular/issues/2031, make the easier to separate the use cases.

[SlavUI]

@grosch closing this one if necessary re open. Hope we answered your questions :)