IgniteUI / igniteui-angular

Ignite UI for Angular is a complete library of Angular-native, Material-based Angular UI components with the fastest grids and charts, Pivot Grid, Dock Manager, Hierarchical Grid, and more.
https://www.infragistics.com/products/ignite-ui-angular
Other
568 stars 159 forks source link

IgxCombo with single selection #9832

Closed Timmeeeey closed 2 years ago

Timmeeeey commented 3 years ago

Question

I have a potentially large list and I need a dropdown component with the ability to filter/search. The IgxAutocomplete doesn't have the ability to scroll through all available values. The IgxCombo would be perfect but it forces multi selection. This behavior can be changed with onSelectionChange like described in the documentation but the value of the component is still an array. Are there any plans to add a singleSelection mode where the value is not an array but a single object? I think a single selection dropdown with filter is a quite common use case.

Lipata commented 3 years ago

@Timmeeeey IgxAutocomplete should have all available items with scroll. If you don't see a scroll, can you send me a sample because what you are describing should be a bug that needs to be fixed? Here are IgxAutocomplete samples. Reading your case I think IgxAutocomplete should be what you need.

Here is a detailed answer about differences between IgxCombo, IgxDropDown, IgxCombo and IgxAutocomplete.

Timmeeeey commented 3 years ago

I have an array of objects like [{id: 1, name: 'Item 1'}, {id: 2, name: 'Item 2'}]. The dropdown should display the name property and the model should be the id and I want the ability to filter the list. All this is possible with IgxCombo via valueKey and displayKey and filtering works out of the box but only with multi selection. IgxAutocomplete displays the id after a value is selected and you can't click on any button to open the list of available values without typing something. Also the user isn't forced to select something from the list.

Eralmidia commented 3 years ago

I agree on this one. The onSelectionChange solution in the docs is ok, but a more true single selection would be better.

Lipata commented 3 years ago

@Timmeeeey with the last details you have provided it seems that igxAutocomplete is not applicable for your case, because it is more an addition to the input, where you can have suggested items, but at the end, you can type anything. The autocomplete uses IgxDropDown which is declarative, which is different from the combo where it is data bound-able and you have value and text keys.

@Timmeeeey, @Eralmidia, as you both pointed out, our demo is our current solution that is using the onSelectionChange event. When we talk about such a single selection feature to come out of the box, we will need to think about the proper UX - eventually remove the checkboxes and decide what we will do with both inputs. You have already shared you expecatiotions about the behavior - like it should be data bounde-able with value and text keys, it should be able to select items only presented in the drop-down list, search, etc, and you can always share if you have some other requirements.

@Timmeeeey, igxSelect can also be a solution for your case. Even though you don't have filtering, when select is on focus you will be able to search an item, just by start typing. You will not be able to see what you are typing, but the list will scroll to the matched time anyway. Check this demo - start typing "Potato" or type "p" several times to see how you will be navigated through the matched items.

Timmeeeey commented 3 years ago

@Lipata I really like to have a real filter like in IgxCombo, so IgxSelect doesn't fit. The only thing I'd like to have on IgxCombo is a selectionMode="single" with an object as model instead of an array. I don't mind the checkboxes. I really hope that there will be such a single selection mode in IgxCombo in the future. Until then I will have to create a wrapper component for IgxCombo which converts an object to the required array and back.

kdinev commented 2 years ago

@Timmeeeey @Lipata I'm OK with adding a single selection mode in the combo, if that doesn't also require a template change (removal of the checkboxes). I really want to avoid *ngIf-ing the combo template!

Timmeeeey commented 2 years ago

@kdinev That would be great! The checkboxes are ok for me. I just want to be able to use an object as model instead of an array.

kdinev commented 2 years ago

@Lipata Can you guys look at potentially implementing this next sprint, if it's possible?

radomirchev commented 2 years ago

Hi @Timmeeeey , the feature request is added to the next sprint planning. We would try to include it in the next major release - 12.1.0, expected to be released in the beginning of August.

ViktorSlavov commented 2 years ago

@Timmeeeey @Eralmidia I've created a PR that will implement an input for the combo, allowing you to toggle selection mode between "multiple" (the default and current behavior) and "single" (same behavior as the sample from the docs, out of the box). This change is scheduled to make it into the Aug release, as @radomirchev mention.

@Timmeeeey The combo currently has a lot of internal logic for handling whatever is passed in the array (the data passed can be either primitives (string, number) or complex (object)) both with and without the presence of a valueKey and displayKey. I fear that logic to handle binding to an object (or a string or number, as that's currently also supported) would require a large amount of internal logic and testing and impact the overall maintainability of the component. As far as I understand, if you want your control's property to be an object (instead of an object[]), you could achieve that behavior with a pipe (to wrap it into an array, going in) and a handle (to revert it, going out).

Please check out this StackBlitz and let me know if this approach could resolve your scenario.

Timmeeeey commented 2 years ago

Unfortunately I use reactive forms with formControlName instead of ngModel so I can't use pipes there.

ViktorSlavov commented 2 years ago

@Timmeeeey @Eralmidia After further internal discussion, we've decided not to proceed with the existing PR, as implementing a single property w/o addressing the chechboxes or binding concerns will not cover all bases. For single selection, please use the sample from the docs.

As mentioned above, allowing the combo to be bindable to a single instance (instead of an array of instances) would require complex refactoring (and, inevitably, introducing breaking changes to the API) - we have decided the scope of that is too great and will not be going forward with it, for the time being. That said, thank you for the feedback and the valid concerns you've voiced - we will consider this refactoring for a future iteration.

github-actions[bot] commented 2 years ago

There has been no recent activity and this issue has been marked inactive.

kdinev commented 2 years ago

@Lipata Please update this issue with info on the new "simple" combo and a link to the spec!

@Eralmidia @Timmeeeey I think you will like what's coming! :)

Eralmidia commented 2 years ago

@kdinev This is interresting 😉 Actually, we are in the process of making a component like this ourselves just now, after this was turned down. I'm a bit unsure what we should do regarding this then. Is it too early for an eta of this? We need a solution for this for our next release towards the end of the year, so if this is a next year type of thing, we may need to use our own implementation at least for this release.

Eralmidia commented 2 years ago

Just noticed this has a pull request, so guessing it might now be too far of?

kdinev commented 2 years ago

@Eralmidia It's not. We were demoed a fully functional component last Friday, so we should be able to push it out very soon.

@Lipata I suggest we include this component in 12.2.x. I know that goes against the policy to not release features in minor versions, but otherwise we will have the component ready and users will have to wait until Angular 13 to use it.

Eralmidia commented 2 years ago

@kdinev @Lipata Thanks. We won't be upgrading to Angular 13 until early next year, so getting this into 12.2 would be great.

Lipata commented 2 years ago

@Eralmidia, @kdinev we will include it in 12.2.x. Here is the spec.

Eralmidia commented 2 years ago

@kdinev Any chance we're getting it this week? 🙏 We actually have 3 feature branches simply waiting for this one in order to start the pull request 😉

kdinev commented 2 years ago

@Eralmidia We will discuss it at our sync meeting today and we will post an update in the issue this afternoon.

Lipata commented 2 years ago

@Eralmidia what we can do is to release 12.3.0-alpha.0 (which will be 12.2.3 + simple combo) by the end of the week so that you can test it. We still have work to do and if everything is ok we plan to release 12.3.0 next week.

Eralmidia commented 2 years ago

@Lipata Sounds good, looking forward to testing it 👍

Eralmidia commented 2 years ago

@Lipata Quick question: Should the alphas be available through npm, or do you need to download them manually or something like that? I believe I tried accessing an alpha version earlier, and that I couldnt get that to work through simply updating the package in the package.json.

Lipata commented 2 years ago

ng update igniteui-angular@12.3.0-alpha.0 should do the work. Updating directly in the package.json should also do it, after you run npm i, but the latter will skip if there are migrations to be run, that is why it is recommended to use ng update.

Lipata commented 2 years ago

@Eralmidia we've just released 12.3.0-alpha.0, so you can try with ng update igniteui-angular@12.3.0-alpha.0. With alpha versions, migrations are not run, so that in addition you need to run ng g igniteui-angular/migrations/migration-collection.json:migration-22, because there are some API changes in the already existing igx-combo. Here is also a code, for using the igx-simple-combo.

Eralmidia commented 2 years ago

Thanks, @Lipata

We'll check it out tomorrow 👍