Feature: Possibility to make the [displayWith] of Autocomplete more flexible

[dev054]

Bug, feature request, or proposal:

Feature Request.

What is the expected behavior?

I expect [displayWith] to give me back the whole object so I can treat what property I can return to display (doesn't it make sense)?

What is the current behavior?

Actually [displayWith] is too limited.

Ex:

I have the following variable that gets the content from API:

this.myObs = this.<service>.<fetch>();

That's the content coming from back-end:

[
  { id: 1, name: 'anyName' },
  { id: 2, name: 'xxx' }
];

In template I have:

<md-input-container>
  <input mdInput placeholder="State" (keyup)="onKeyUp($event)" [mdAutocomplete]="auto" [formControl]="objCtrl">
</md-input-container>

<md-autocomplete #auto="mdAutocomplete" [displayWith]="displayFn.bind(this)">
  <md-option *ngFor="let obj of myObs | async" [value]="obj.id">
    {{ obj.name }}
  </md-option>
</md-autocomplete>

Since, I'm binding the md-option to id, [displayWith] just gives me the value of id while I was expecting at least the full object so I can return the name, for example.

Workarounds:

1- Subscribe to the observables and store in arrays.

Problem 1: You'll have to loop through the array everytime that an option is selected to return the desired property.

Problem 2: Imagine that I have more than 10 autocomplete (my case), I'll have to create 10 variables and subscribe them all while I could simply use the async pipe (as I'm doing) and, consequently I wouldn't need to subscribe in nothing.

2 - Bind the full object to <md-option>, so [displayWith] will give me back the whole object.

Problem: If your API expects a single property (in my case back-end expects only the id), before submits the form, you'll have to change the whole content of form that was stored as object to id.

What are the steps to reproduce?

Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: https://goo.gl/DlHd6U

What is the use-case or motivation for changing an existing behavior?

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Material 2.0.0-beta.6

Is there anything else we should know?

The workarounds can be used? Ofc they can, however it'd be really better if Material2 could provide a better solution for this.

[un33k]

@dev054 Thanks for raising this issue.

There may be two simple options:

1. MD takes care of everything for us, we give it a displayFn and an object instance. In this case, MD calls the displayFn with our instance object. We format the display and pass it back. Inturn MD will populate the innerHTML of <md-option></md-option>(s) with the returned display names. The [value] remains what we set it to.

<md-input-container>
  <input mdInput placeholder="ComplexObject"  [mdAutocomplete]="auto" [formControl]="objCtrl">
</md-input-container>

<md-autocomplete #auto="mdAutocomplete" [displayWith]="displayFn.bind(this)">
  <md-option *ngFor="let obj of myObs | async" [instance]="obj" [value]="obj.id"></md-option>
</md-autocomplete>

2. MD expect us to do it all. We have a simple name and just go about displaying it. The good old way.

<md-input-container>
  <input mdInput placeholder="ComplexObject"  [mdAutocomplete]="auto" [formControl]="objCtrl">
</md-input-container>

<md-autocomplete #auto="mdAutocomplete">
  <md-option *ngFor="let obj of myObs | async"  [value]="obj.id">{{obj.name}}</md-option>
</md-autocomplete>

@dev054 - the plunker seems to be unrelated. Removing it or providing a relevant one may help others.

[francois-appliware]

Hi,

I am interested in that issue as well, as I have the same needs that @dev054 . (In the single ID asked from the server and the multiples autocomplete in 1 form.)

Is there any news on what is intended for that ?

Isn't there a way to use the same template in the md-option to show the selected value, instead of stripping everything and put a single string ? (in case of using the md-icon for example, the selected value shows the code of the icon and not the icon itself).

[robert-king]

this whole displayFN doesn't make sense to me. Why not just use displayValue and bind to a value in the component. (e.g. [displayValue]="myDisplayValue")
Then using (onSelectChange) one can update displayValue if they like. My problem is that i need to update displayValue when the user navigates e.g. browser back and forward buttons. There isn't a way to do this with displayFN since displayFN only gets called when you select a new item in the autocomplete. Unfortunately, my autocomplete value also updates if the URL of the page changes.

[rafaelss95]

Wouldn't it makes more sense if the [displayWith] gave us the whole option (of <md-option>) instead of only the [value]? I think It'd solve all problems.

@jelbourn

[Aaron-Zhao]

I have the same issue. In my case, I also need to restore the display from saved values..

I can see why displayWith is taking in value rather than the whole object. It's because value is what the form control stores, and when you revisit your "draft" form it has to reconstruct the "display" from something, and in this case it is your stored value.

The workaround is to tell your OnSubmit to take in ID of your object, otherwise you will have to do some dirty hacks (e.g. storing display locally and reconstruct display by querying your db matching the id when visit your "draft").

[willshowell]

Alternatively, what if when displayWith isn't defined, the trigger displays the MdOption's viewValue instead of value?

That, or as @rafaelss95 suggested, the MdOption is passed to displayWith, so the user can choose.

[RAlfoeldi]

My usecase is slightly different. My values are Observables and the options are rendered as

<md-option *ngFor="let newUser of users" [value]="newUser" disabled={{!(newUser|async).name}}> {{(newUser|async)?.userName}} - {{(newUser|async)?.name}} </md-option>

My problem is that a displayWith() function has no way of synchronously returning a value and I don't see an option of having the displayWith value rendered as interpolation, e.g. {{(newUser|async)?.userName}}

[sarora2073]

Hi,

To aid discussion and provide a working reference implementation, I've posted a plnkr. Unfortunately I don't know what's wrong with the typical plnkr template itself (known issue apparently), but at least you can see the code itself here:

http://plnkr.co/edit/rw8OYeXtRTPnYfLRsqtv

I understand the original argument about wanting to have the autocomplete work with the full object. Given the amount of component code in the plnkr that has to used just for one autocomplete, and the complexity, I agree it would be nice to reduce some of this if possible, especially when making forms with numerous autocompletes. That said, I believe the plnkr demonstrates that it is possible to get all the typical desired functionality working.

I would strongly advise that whatever solution is under consideration retains some of the existing design in terms of binding [value] to the object's value (a.k.a. id), NOT to the entire object. The reason becomes clear when you try to persist the data or patch the form on reload - using id is simplest.

I also believe it's easy enough in the status quo to work with the entire object in the component code as it is, relying on a mapping function like that used by displayWith to convert from value to viewValue as necessary.

So in summary, I slightly disagree with @dev054 in terms of what the concerns ought to be and how we tackle them, because I see value in the existing design, but I don't disagree in spirit that it would be nice to improve the autocomplete's ability to rely on less code if we provide the full object as an option.

Regards,

• S. Arora

p.s. @RAlfoeldi -- the plunkr contains a way to pre-empt the need for interpolation by doing the string manipulation in the loadCompanies() method.

[RAlfoeldi]

@sarora2073 : Thanks for the p.s. but what the plunkr does is cache the values and use the cached values in displayWith(). That works... but isn't really what I would like to do as both the list of values (actually only the ids of the values) as well as the values themselves are Observables, i.e.: getCompanies() returns an Observable of Observables.

[sarora2073]

@RAlfoeldi - Not sure I follow your objective in using autocomplete exactly. Common use-case is to load a single collection (view / viewValue) and bind those to the drop-down, then allow autocomplete to filter that single collection based on user entry, and in this use-case you can leverage displayWith to map selected value to corresponding viewValue.

Having said that, the displayWith function can handle any kind of return value though..it could perform additional operations e.g. a second lookup on another collection, if that's what you're trying to achieve perhaps. i.e. there's no built-in constraints inherently in that function..just takes an input (selected value) and returns an output to display. btw, I find it's much easier to work with displayWith if you bind the md-option to the [value]="newUser.value" (assuming that 'newUser' is the object you created). Binding the entire object sounds trickier to me at least.

Additionally, I was suggesting you do something similar to the loadCompanies() function in the plunker to pre-load the data you retrieve and get the data structure you want up-front (it can be 'value' / 'viewValue' and additional fields with interpolated values if that helps), then use displayWith to just return any of those fields depending on what is selected..that might be better for performance / separation-of-concern angle, and avoid having to do a second data lookup in the displayWith function, but if you really need to do a lookup from a second data source on the fly (i.e. in displayWith) you can. Hope that helps.

[RAlfoeldi]

@sarora2073:

there's no built-in constraints inherently in that function

Not quite. displayWith() requires an immediate, synchronous return value. As I only have Observables to work with, that is something I cannot do without resorting to caching values - which I really don't want to do - at least not at this level.

And thanks for the suggestions with the preloading and the separation of concerns idea... Sounds like a good idea and like what we've built: a dedicated service returns an Observable of Observables matching the current input of the autoselect. Once lists of possible values are retrieved from the server they are centrally cached, once retrieved values are centrally cached; but - as we're dealing with Observables - both are returned - and potentially updated - asynchronously. Works like a charm in a fairly large system (updates pushed from the server to multiple clients right into the UI - no extra code required) - except for with displayWith().

In other words... a fully asynchronous solution using Observables would greatly appreciate interpolation in displayWith().

@ anybody else: our application does not handle 'data' until the very last possible moment. This is by design and fits well with reactive concepts. (As soon as you hold on to the value of an Observable, you're stuck with it - so we don't.) We use interpolation for all rendering of data and up till now this has worked everywhere - except for displayWith(). But this is getting slightly off topic...

[sarora2073]

A while ago @willshowell asked me to look at this discussion so i'm going to chime in again with my 2 cents on where I think this whole discussion landed...hoping to help bring some closure.

This argument for binding to the "whole object", and allowing the displayWith function to work with that was proposed to reduce the amount of code, improve performance, and to maintain use of Observables throughout. Personally I don't "get" what kind of magical code could accomplish the latter without presuming too much about the use case, and so given that that appears to be the main argument I'd suggest closing this issue absent a clear design path forward.

The current design for autocomplete, verbose though it may be, maintains some important benefits which I'd would advocate to retain:

1. By explicit binding to the id (not the whole object) we can determine what id value to persist to the db. Storing / patching the whole object doesn't sound like a best practice.
2. Explicit definition of the displayWith function provides some implementation flexibility as well.

Hope that helps.