ng-model not binding <select> list values in 1.4.rc2

[RickStrahl]

I have a list of static values that are bound to a list and I'm trying to get the list to display the value from the model.

The model value is an integer:

wm.activeResource.ValueType = 0;

Then in the html I'm binding this value to a dropdown list of static values:

{{view.activeResource.ValueType}}  <-- correctly displays 0 -->

<!-- list displays empty element --->
<select ng-model="view.activeResource.ValueType">
    <option value="0">Text</option>
    <option value="2">Markdown</option>
    <option value="1">Binary</option>
</select>

This worked fine in v1.3 but in 1.4 the list comes back with no selection. Or, more specifically it has a selection of an injected element:

<option value="? number:0 ?"></option>

[Narretz]

Is this a correct reproduction? http://plnkr.co/edit/k09Xh9xEgcXQBbKTkRdh So the select does not reflect the model?

[petebacondarwin]

The reason for this is that in 1.4 we test for exact equality in the select directive.
If you have static options then the values of these options are strings.
See http://plnkr.co/edit/KCM6Kz22sB5GVcPvOZgT?p=preview

You can provide a simple directive to convert the value from number to string and back between the model and view: http://plnkr.co/edit/BnNkVENvNYyArbRjVaov?p=preview

[petebacondarwin]

We should probably highlight this in the docs for select if it is not already.

[RickStrahl]

While I think that this makes sense conceptually and probably for performance as well, I think this has a terrible usability aspect. I would imagine that this is a fairly common scenario that needs to be addressed and there's no intuitive discovery of this behavior until it fails. If you're new and starting out you're not going to make the connection that you have a type conversion problem.

Even the solution of requiring a custom directive to make this work seems heavy handed. Shouldn't there be something built in to provide these types of conversions for you more easily without having to create a component?

I don't want to derail this issue - the solution given is straight forward enough for me to fix and I can live with that. Thanks for pointing to the source of the issue and the solution!

But I think in the grander scheme of things this should be thought over going forward (not sure how this will be handled in 2.0).

[Narretz]

We previously compared the model and attribute value with == which did type conversion. However, did caused false to be equal to 0 for example. Also bad. The root problem is simply that HTML does only allow strings inside value attributes, so your integers become strings in the DOM. You can use ngOptions to remedy this problem.

[petebacondarwin]

A more pernicious issue with using == and implicit conversion is that on the way "out" of such a select your model would change from being a number to a string.

[petebacondarwin]

I updated the select docs to highlight this issue and to provide a running example of using a custom conversion directive.