Running AngularJS 1.4.0-rc.1 the value within a ng-options loop contains the type of the variable.
See the following code:
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.1/angular.js">
</script>
<script>
angular.module("selectOptionsTest", []).
controller("SelectOptionsController", ["$scope", function($scope) {
$scope.options = [
{id: 1, label: "Item 1"},
{id: 2, label: "Item 2"},
{id: 3, label: "Item 3"}
];
}]);
</script>
<div ng-app="selectOptionsTest" ng-controller="SelectOptionsController">
<select ng-model="opt" ng-options="option.id as option.label for option in options">
</select>
</div>This generates HTML code which looks like this:
<select ng-options="option.id as option.label for option in options" ng-model="option" class="ng-pristine ng-valid ng-touched">
<option value="?" selected="selected"></option>
<option value="number:1" label="Item 1">Item 1</option>
<option value="number:2" label="Item 2">Item 2</option>
<option value="number:3" label="Item 3">Item 3</option>
</select>
Why is the value prefixed by the type of the variable, i.e. number:? In previous versions of AngularJS (e.g. the current stable 1.3.15) the value attributes are filled with the expected values of 1, 2 and 3.
So is this a bug in 1.4.0-rc.1 or do those cases need to be handled differently now?
Obviously there was a change in how the ngOptions directive is handled. This change is briefly explained in the migration notes for AngularJS 1.4. A more detailed description of the changes can be found in the commit message:
When using
ngOptions: the directive applies a surrogate key as the value of the<option>element. This commit changes the actual string used as the surrogate key. We now store a string that is computed by callinghashKeyon the item in the options collection; previously it was the index or key of the item in the collection.(This is in keeping with the way that the unknown option value is represented in the select directive.)
Before you might have seen:
<select ng-model="x" ng-option="i in items"> <option value="1">a</option> <option value="2">b</option> <option value="3">c</option> <option value="4">d</option> </select>Now it will be something like:
<select ng-model="x" ng-option="i in items"> <option value="string:a">a</option> <option value="string:b">b</option> <option value="string:c">c</option> <option value="string:d">d</option> </select>If your application code relied on this value, which it shouldn't, then you will need to modify your application to accommodate this. You may find that you can use the
track byfeaure ofngOptionsas this provides the ability to specify the key that is stored.
This means that you now need to use track by to get the same result as before. To fix the example in the question it needs to look like this then:
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.0-rc.2/angular.js">
</script>
<script>
angular.module("selectOptionsTest", []).
controller("SelectOptionsController", ["$scope", function($scope) {
$scope.options = [
{id: 1, label: "Item 1"},
{id: 2, label: "Item 2"},
{id: 3, label: "Item 3"}
];
}]);
</script>
<div ng-app="selectOptionsTest" ng-controller="SelectOptionsController">
<select ng-model="opt" ng-options="option.id as option.label for option in options track by option.id">
</select>
</div>See migration guide for kind of obscure explanation of this breaking change, under the ngOptions heading.
Due to 7fda214c, when ngOptions renders the option values within the DOM, the resulting HTML code is different. Normally this should not affect your application at all, however, if your code relies on inspecting the value property of elements (that ngOptions generates) then be sure to read the details.