bug(select/ngOptions): switching to a valid model value via $setViewValue doesn't update selected value

[tdakhla]

In 1.3.1, when I call $setViewValue inside a directive and the value I'm switching to is a valid ng-option value, the select switches to the correct value: http://jsfiddle.net/8mgc0dv2/.

In 1.3.2+, given the same behavior, the select doesn't switch to the correct value: http://jsfiddle.net/g15o09t2/

In both 1.3.1 and 1.3.2+ (including 1.4 snapshot), if I set the model value directly inside a controller after a $timeout, the select switches to the correct value. I looked at the changelog and this may have been introduced per 9e30594, but I'm not 100% sure.

[tdakhla]

Update:

I was able to solve this by basically doing $parse(attrs.ngModel).assign(scope, newValue) instead of ngModel.$setViewValue(newValue): http://jsfiddle.net/LLsvdq02/.

Basically, it looks like in the $setViewValue case, when the ngModelWatch occurs, the control's modelValue and the actual modelValue are in sync so it never calls render() to go and update the select. And in the $parse case, since the model is being set directly outside of any directive, the control's modelValue and the actual modelValue are different so render() is called.

After thinking about this a bit, I think the 1.3.2+ behavior actually makes more sense because $setViewValue assumes the user has taken over "ui updating" responsibilities. $parse seems cleaner as well. What do you guys think?

[Narretz]

In 1.3.2, we changed a specific check to use === instead of ==.
However, it makes sense to me that it doesn't work now. When your model is '20000' and you are setting the $viewValue to 20000 you are skipping the complete ngOptions matching phase, and the $render phase. Changing the select should either be done by the user or driven completely by the model.
I also can't see that the select value is changing in 1.3.1 when calling $setViewValue inside the parser - the select changes when setting the model because we didn't use strict equality checking in 1.3.1
'

[tdakhla]

Thank you for the response Narretz. I realized that $setViewValue wasn't even the cause of the select updating in 1.3.1, but it was rather the equality check like you were saying. And yeah, only a change event or a $render invocation (via model change) causes the dropdown to update. The $parse/completely model driven approach seems to be the correct way of handling those types of situations.