Repository navigation
ngOptions not Observing Changes in Backing Model #8651
Description
Plunkr for this here
This problem seems to have been introduced in the change from "1.2.21" to "1.2.22" and I guess it might have been as a result of this change;
do not update selected property of an option element on digest with no change
event (c286094, #8221, #7715)
In my application, I am using an HTML select with options like this;
<select
ng-model="selectedXyz"
ng-options="anXyz.title for anXyz in allXyzs">
</select>The "title" property starts off being a string "..." then the actual value for each "title" property is set after a promise is resolved some time later. In this way, the "option"-s titles start off as "..." and then become human readable strings. This technique is used because the titles are localized for the user's language and the localization data may need to be obtained from a server; ultimately using an HTTP request. The user may also change their language settings from time to time and so the "title" property would be refreshed in the same way.
This approach worked well in 1.2.21 and prior, but in 1.2.22 it fails. The model is correctly updated, but unfortunately the user interface "option"-s do not update their titles. It would seem reasonable that changing the data model behind the "option"-s titles should be reflected in the user interface.
Activity
caitp commentedon Aug 19, 2014
Well, this should be a breaking change noted in the changelog, but I'm pretty sure this is what we want. You should be able to work around it by dispatching a change event with jQuery, I think
caitp commentedon Aug 19, 2014
http://plnkr.co/edit/2ynZaYKGFDT6WGwrUKbe?p=preview << for example
Alternatively, you should be able to manually invoke $render like so: http://plnkr.co/edit/QWXvN7zqaxeLZsZCksLX?p=preview
caitp commentedon Aug 19, 2014
You have to be a bit more explicit, but we get a bit of a performance enhancement and fix some bugs this way, so this is a good thing =)
andponlin commentedon Aug 20, 2014
@caitp -- It seems a shame to break the "change-observing" nature for the ngOptions because the model is nice, but I can see plenty of discussion and thought has gone into #8221 and #7715 so this must be necessary. Thank you for pointing out those work-arounds. I will close this issue.
jyonker commentedon Aug 28, 2014
@caitp Thanks for explaining this breaking change. Is there a way to get a different workaround? All of the documentation about angular warns against using $element in a controller. In fact, Misko says "Yes this goes deep against the angular way...." https://groups.google.com/forum/#!msg/angular/SYglWP_x7ew/lFtb75NWNWUJ
tkrotoff commentedon Apr 13, 2015
Ping @caitp
With 1.3.15 the plunker from @aplgithub works
With 1.4.0-rc.0 it does not anymore => regression
See the updated plunker: http://plnkr.co/edit/i56Jig?p=preview
caitp commentedon May 1, 2015
I can't even remember what all happened with ngOptions, but I think pete is doing some work on it right now, ping @petebacondarwin
petebacondarwin commentedon May 1, 2015
I believe that this might be a dupe of #11765
mariyanang commentedon May 7, 2015
any workaround for this in 3.1.15 without accessing the DOM from controllers?
petebacondarwin commentedon May 7, 2015
This is working in 1.3.15 is it not? See http://plnkr.co/edit/ZVRZVI?p=preview
mariyanang commentedon May 7, 2015
I can't manage to get it working. Here is my case http://plnkr.co/edit/jI7KdQJXa1WyUOS8oQaR?p=preview I don't understand why the span is immediately updated when you click 'Change oak to mooo' but the select option is not. Any input is much appreciated.
petebacondarwin commentedon May 7, 2015
Ah! You are talking about 1.2.22 - we were talking about 1.3.15 and 1.4.0