ng-options doesn't work well when using objects

[coli]

http://jsfiddle.net/ADukg/658/

The example uses ng-options to provide 3 different objects which can be selected. All works until you switch to the next section then comes back. As the implementation uses object comparison, Angular can no longer match the current selected with the datasource.

Conceptually, ng-options should store the 3 selection objects (somewhere) and their lifespan is tied to the "data" object's scope, and not to the ng-options's proxyOptions lifespan.

Also, the comparison should be on a key, and not on the object, in this example, the key is proxyType, there currently is no way to provide the key field to ng-option while still using the object as the value.

[coli]

BTW: this is our workaround right now

<select ng-model="config.proxy.proxyType"><!-- objects comparison doesn't work well, so use key comparison instead -->
            <option value="None">None</option>
            <option value="Manual">Manual</option>
            <option value="Automatic">Automatic</option>
        </select>

Basically, instead of 3 objects for each type, we now use 1 object to store the sum of all types.

This workaround isn't too bad, just we needed to have type specific serialization logic in the service layer now.

Try this:

<select ng-model="data.selected" ng-options="p.proxyType as p.proxyType for p in proxyOptions">
</select>

And this in the controller:

$scope.data = { selected: 'None' };

http://jsfiddle.net/ADukg/670/

[coli]

Yeah, that is the workaround. This bug is about the object syntax not working well in practice, and a possible way to fix it.

[qualidafial]

Also, the comparison should be on a key, and not on the object

This would be a huge help. My application is loading the items from a ReST resource, and the selection is being loaded from another resource.

I suggest "identified by {expression}" as a way to differentiate arrays of object items:

<select required ng-model="widget.item" ng-options="i.name identified by i.id for i in items"></select>

[marcalj]

I cannot understand why the select with no empty option shows empty option <option value="?" selected="selected"></option>

Also for this example: http://jsfiddle.net/3y5Pw/

I'm expecting no empty options in the select.

[marcalj]

Sorry, I found this answer that solved my question.
http://stackoverflow.com/questions/12654631/why-does-angularjs-include-an-empty-option-in-select

[jperl]

👍 commented to watch this

[jperl]

Also I made a directive to automatically apply a workaround. See http://jsfiddle.net/ADukg/2226/

[vgrivel]

@qualidafial Hi, did you find a solution with your Rest resource, because I have the same problem.

[qualidafial]

@vgrivel Sorry for the late reponse. I wouldn't call it a solution, but rather a workaround.

Basically, after loading the resource, I search through the array of options being used in the select element, and set the resource property to the option that matches. That way you have an identity equals. It's ugly but it works.

[tschiela]

@qualidafial i use the same way to do that. Is there any new solution for that out now? I need key comparison in ng-options instead of whole object comparison for array of objects.

[qualidafial]

@tschiela I haven't seen anything yet.

In my case, I ended up using "select as name for item in items" and only storing the item ID (the select part) in my model.

[danielgatis]

take a look at http://configit.github.io/ngyn/#select_extensions

[cm325]

to deal with providing objects to the filter expression, I used this solution:

http://plnkr.co/btcROVvJHNI2PwWi1o4X

where I take the value of the select, and then pass it to the filter expression after manually converting it to a real object-

[asgeo1]

I was able to use the "select-key" extension from ngyn, and it worked well.

Would love to see this issue fixed properly in Angular though!