Kendo-angular: AutoCompleteComponent: Arrays of Complex Data

Created on 3 Feb 2017  路  11Comments  路  Source: telerik/kendo-angular

Hi, we are testing the AutoCompleteComponent and it is confusing.

When binding to array of complex data (objects) the auto complete does not emit the selected object but rather the value of the matching "valueField" property of the selected object which actually defeats the purpose of binding to array of objects.

Plunker: http://plnkr.co/edit/ryLAkm0Ohwi1JvYOONR9?p=preview

The DropDownList works with array of objects as expected, it emits objects in the ngModel: http://plnkr.co/edit/0F3h1CoBzq8Qav2sTkvO?p=preview
For reference the jQuery kendo autocomplete works as expected as well: http://demos.telerik.com/kendo-ui/autocomplete/mvvm

dropdowns

Most helpful comment

I feel like i should back up @burkeholland on this (and because the issue was opened by me 馃槃 ). I spent more than 6 hours trying to figure out why the AutoComplete didn't work with complex data or more accurately why it accepted but did not emit complex data upon selection.

I too understand the idea behind what @ggkrustev is saying but still on our team we are using PrimeNG's auto complete, because it just works and because I don't have the time at the moment to try and force ComboBox to behave and look like AutoComplete with complex data.

Maybe an option to remove the arrow from the ComboBox would make it look more like AutoComplete and maybe including in the docs something like "If you need AutoComplete to emit complex data use ComboBox with [toglleButton]="false"" would be helpful for developers 馃槃

All 11 comments

Hi @moxival

The AutoComplete component is based on the native input element and therefore is designed to work with string values, as mentioned in the documentation. We recommend using the ComboBox when binding to objects is necessary. You calso enable the allowCustom option to get a behavior more close to the AutoComplete.

Hi @tapopov thanx for the reply.

To be honest it is really confusing, the autocomplete is based on the native input and it is designed to work with string but it can bind to complex data and is placed in the DropDowns category where the rest of the components do bind to complex data and are emitting complex data, furthermore it does not behave as the jQuery version of Kendo (not that it should but still confusing)

I might be wrong but I think it would be really nice if everything inside DropDowns could emit complex values else I don't really see why would i want to bind to objects in the first place.

Hi @tapopov :) i found this issue #102 and i can see that this is was discussed and it is by design, so if you think there is no chance that the autocomplete will emit objects (it is not needed by the users) you can close the issue and we will try to use your suggestion.

Hi @moxival

Indeed, the AutoComplete does work with string only by design and this is unlikely to change. Otherwise we pretty much get a ComboBox without the open arrow button.

I think it's worth re-examing having a textField and valueField field just like the ComboBox and DropDownList. This is primarily for an improved developer experience. Here are a few of the things that I ran into when troubleshooting this issue.

  1. That's how the DropDownList and ComboBox work, so the developer will assume that's how the AutoComplete works as well. A developer will likely spend a lot of cycles trying to figure out why this component behaves differently. Is the API incomplete? Is the documentation incomplete? These are things a developer will likely research before they figure out that we expect them to use a ComboBox. In fact, the only way to find that out is by doing Google searches and finding the right GitHub issue or StackOverflow question.

  2. While the ComboBox is an adequate replacement for the AutoComplete, it is not an AutoComplete. The developer will be spending extra cycles to make the ComboBox behave like an AutoComplete. This includes the allowCustom flag as well as trying to get rid of the DropDown arrow in the corner. Their customizations might not get them to the point where they have a functional AutoComplete that returns text and value, which is ultimately what they are after.

  3. I understand why the AutoComplete only returns the string for valueField, but in order for the component to be useful outside of its visual properties, a developer is almost always going to need an associated id or key that can be used to select the object from the collection.

Hey Burke,

We've put a lot of thought before we even started working on the components and the AutoComplete is no exception. There is no perfect solution for every case and every person though.
Allowing object values in the AutoComplete will create the same problems the ComboBox has and will inevitably force the developers to use a valueNormalizer for even the simplest of scenarios.
The argument "X and Y work the same, why is Z different?" is too weak to make the AutoComplete an exact duplicate of the ComboBox feature-wise. The documentation is pretty explicit in regards of what the AutoComplete's value type is, but perhaps we can emphasize it a bit more, so people don't end up in GitHub, SO or our ticketing system. Adding an example of ComboBox that emulates an AutoComplete is also a good idea.

Thanks for the update here.

I checked around to see what other AutoComplete implementations are doing. With Angular Material, and they are providing a solution for this using a displayWith attribute. PrimeNG is doing it with a valueKey attribute.

I suggested the text and value since that was consistent for our API, but I still think that without a way to get the object or key for the selected item in an AutoComplete, the control's effectiveness is diminished.

While you could use a ComboBox as an AutoComplete, I don't think this is the best solution since there is already an AutoComplete component that doesn't work the way one would expect.

Hey Burke, IMHO that the linked components are more like ComboBox than AutoComplete. I prefer to rely on the W3C group for a better explanation which control is what.

Historically (back in the "Telerik Extensions" days) we decided to split the functionality of one mighty ComboBox into separate controls/widgets/components (retrospectively ordered), which proved to be a better decision in a long run.

Right now, we've got

  1. ComboBox provides:
  2. filtering
  3. track the selected data item
  4. more

  5. AutoComplete is a simple type-a-head component (similar to the Google search box)

I don't see why we need to duplicate the ComboBox and name it AutoComplete. Much better will be to just provide an easy way to hide the toggle button of the ComboBox component.

If you're worrying about the naming, I'm afraid that we use this convention even before PrimeNG and Material. If you see some holes in the documentation, then this is the moment to point it out :).

As a side note, we can make an info graph that will help people to decide which components is more suitable for their needs. Do you think this will help?

There are solid academic reasons to back up the current state. I will not argue that point at all. I think they are well researched and well thought out.

Sometimes, you have to eschew the academic for the practical. If a developer needs an AutoComplete, they are going to look for an AutoComplete, not a ComboBox. It doesn't matter if the functionality is nearly identical. Even if the only difference is a suggest setting on one and an arrow in the corner on the other. The important thing is that we provide a clear path to developers for getting an AutoComplete. No amount of blog posts or documentation is going to help that because most people don't read that stuff - myself included. :)

I won't push any further on the issue after this, but I am convinced that if we don't add this capability to our AutoComplete, we will frustrate people and they won't stick around long enough to figure out that they can build an AutoComplete with a ComboBox.

I feel like i should back up @burkeholland on this (and because the issue was opened by me 馃槃 ). I spent more than 6 hours trying to figure out why the AutoComplete didn't work with complex data or more accurately why it accepted but did not emit complex data upon selection.

I too understand the idea behind what @ggkrustev is saying but still on our team we are using PrimeNG's auto complete, because it just works and because I don't have the time at the moment to try and force ComboBox to behave and look like AutoComplete with complex data.

Maybe an option to remove the arrow from the ComboBox would make it look more like AutoComplete and maybe including in the docs something like "If you need AutoComplete to emit complex data use ComboBox with [toglleButton]="false"" would be helpful for developers 馃槃

It would be great if you provide an example of how to customize the ComboBox to feel as AutoComplete but work as expected with complex data array. Otherwise we all have to look somewhere else for an AutoComplete component.

Was this page helpful?
0 / 5 - 0 ratings