including ng-model in md-autocomplete

[loykianos]

Currently autocomplete uses md-selected-item for parameter initialization.

There are some issues with this, since you can f.e. add a random value/display object and it will show up, even if the item does not exist in the item list, as shown in this example. http://plnkr.co/edit/RkHGrqKXNfjINkuNKIrs?p=preview

I have been struggling the whole day simply to make two autocomplete elements exchange values when an item is selected, when it could be so much easier if I used ng-model. It feels unnecessarily complicated to initialize autocomplete with an object, instead of simply working as a select with the ng-model addressing the desirable value/display pair.

[SidduSomething]

+1

[ilanbiala]

+1 for using native AngularJS as much as possible.

[robertmesserle]

We can't use ng-model due to ambiguity since we have multiple models being bound. We need to allow the user to access both the selected element as well as the text that is entered.

The issue is that there is a lot of gray area between md-autocomplete and md-select - and we are definitely looking into how to best make a clear distinction between the two. It's entirely possible that md-autocomplete will be simplified and some of its functionality be moved into a searchable md-select, but we haven't come to a clear decision yet on what these API's should look like.

[bennsandoval]

+1

[bopm]

👍 I just cant control things like $dirty as long as current implementation not rely on those.

[sharpmachine]

All you gotta do is something like this to get the autocomplete input to bind to a model:

// Controller
var vm = this;
vm.goal = DataService.goals().one();
vm.selectedItemChange = selectedItemChange;
vm.searchTextChange   = searchTextChange;

function searchTextChange(text) {
      vm.goal.name = text;
    }

    function selectedItemChange(item) {
      vm.goal.name = item.name;
    }

<!--View-->
<md-autocomplete
          md-selected-item="new.selectedItem"
          md-search-text-change="new.searchTextChange(new.searchText)"
          md-search-text="new.searchText"
          md-selected-item-change="new.selectedItemChange(item)"
          md-items="item in new.querySearch(new.searchText)"
          md-item-text="item.name"
          md-min-length="0"
          placeholder="Choose a goal or write your own."
          md-menu-class="autocomplete-custom-template">

        <md-item-template>
          <span class="item-title">
            <span> {{item.name}} </span>
          </span>
        </md-item-template>

      </md-autocomplete>

[andrewl64]

+1

[gabor-farkas]

@robertmesserle
this is a painful limitation caused by the way angular was designed: it has a single ng-model directive to handle all data-binding related stuff, including validation. This basically prevents creating reusable components that bind multiple data. If you'd like to create a reusable component for example to edit a person name and address, you can't have two different bindings for that.
It can be a reasonable response to this limitation that in this case you have to create a Person object and bind the web component to that - so the Person object encapsulates all the data you wish to bind.

This still has some pain points of course. If you'd like to add a special validator to the email field when using this component (for example it's required in one part of your app but not on the other), you can easily just use ng-required. But you can still create your own validation directive that plays well with ng-form.

I think this approach might be a good one for md-autocomplete: create an object that encapsulates everything you want to bind. This would let us create validation directives that play nice with ngForm.

[cleever]

+1. And a searchable md-select would be great.

[gabor-farkas]

(@cleever a searchable md-select is a different issue I think :) - in our app we use md-autocomplete with min-length=0, so that clicking in an empty componenet opens up the dropdown - this is quite similar to a searchable md-select, it might work for your use-cases as well)

[cleever]

I understand your point @gabor-farkas. But I think that we don't need two differents components to do similar things. I'm currently using md-autocomplete like you said, but I miss the dropdown arrow and it is a bit confusing for users. Sometimes they have a real combobox(md-select), that is completely static and they cannot search on it and sometimes they have a text input that they can search things but do not looks like a select box.

Cheers ;)

[gabor-farkas]

@cleever yup, I've also tried to have a custom modified md-autocomplete that has a dropdown arrow, but the code isn't easily extensible to support this: the expression you give for md-items actually relies on the expression for searchtext, so you cannot call getSuggestedItems(null) for example from the controller of md-autocomplete. You can only evaluate mdItems. If you set the searchtext expression to null then it will remove the presented value from the dom and it will actually also set the value in md-selected-item to null, so you cannot have the dropdown without actually resetting the value. The code of the md-autocomplete controller would need a lot of refactoring before this can be possible.