$watch doesn't work the way it used to work (regression)

[pocesar]

Clicking the add more buttom should add items everytime the button is pressed, but it doesn't anymore

http://plnkr.co/edit/n9GS0hECnIu2rrYYbu4d?p=preview

Uncomment script tag of beta.19 and try again (watch the items added to the select element, and the console.log messages)

Beta 19:

watch called
refresh called
watch called
(click) add called 
watch called
watch called
refresh called
watch called

rc 2:

watch called
refresh called
watch called
(click) add called 
watch called
watch called

[caitp]

Possibly related to 3f0e642

Can you explain why this matters to you? From the plunker, it looks like the expected behaviour is happening

edit I guess it's probably not that commit if this was apparently working in beta 19

[pocesar]

The built select element is 1 digest behind on rc2 (options wise). The "refresh called" isn't being called immediately after pressing Add more. But it does in beta.19

[caitp]

it doesn't look 1 element behind to me, it looks like it's adding a new option every time the button is clicked...

[caitp]

I am literally watching the DOM update in the debug tools, it looks like it's doing exactly what you're telling it to do.

[pocesar]

Compare both versions, "refresh called" is never called after first press, and subsequently.

Starts out with:

1
2
3
4
5

After first press, the built element should be:

1
2
3
4
5
6

this does happen on beta.19, but not on rc.2. it's not to watch the SELECT DOM element, the problem lies on the $watch never being called.

Because the $watch callback is being called 1 digest behind, the items doesn't match. $('select option').length (the hidden select DOM element) and $('.selectricItems li').length (the built select) after the click. Those numbers match in beta.19

[caitp]

well I mean basically you're trying to run your update after ngOptions does its thing, and this is probably not the right way to do it.

Maybe we could add some method to the selectControl or something, to notify people when the list is re-rendered. That's probably a better solution than trying to watch the DOM

[pocesar]

@caitp although it worked in beta.19 (and all previous versions). selectController is kinda lacking in features right now, and there's no way to watch over the changed current set of options, I already opened an issue #7417 about this lack of feature. relying on setting a scope variable with the result set of a filter feels hacky

[pocesar]

if ng-options could emit for example, the event "$optionsRender" after it finished parsing would solve all the problems, providing the items array as the second parameter.

pseudo-code:

directive('someDirectiveThatDoesSelect', function(){
  return {
     restrict: 'A',
     link: function(scope, el){
          scope.$on('$optionsRender', function(event, items){
             myjQuerySelectPlugin.addItems(items).refresh();
          });
     }
  }
});

[pocesar]

@caitp I'd love to submit a PR (I'm in badly need for this) I just don't want to waste time on a PR that wouldn't be accepted, what is better, an array called $optionsChangeListeners (like $viewChangeListeners in ngModel) or emitting an event?

[lgalfaso]

@pocesar trying to catchup on this. Are you saying that if you have <select ng-model="foo">...</select> and to this ng-model you add a listener to ngModel.$viewChangeListeners, then those listeners will not get called when the value changes?

[pocesar]

@lgalfaso nope, I want to get notified when ng-options is done rendering and be able to know the current set of items (since there's no way to parse the expression on ng-options outside the directive itself). I'm not worried about the current selected select value, but being able to know (anywhere, regardless of scopes) the current list of items, so I can plug the listing to jQuery plugins.

[lgalfaso]

@pocesar ok, got it. We do not emit a lot of events (AFAICT, only ng-include and ng-view do), so other options would be best. That said, the PR would not be simple, so I am not sure how open people would be to the change

[caitp]

An event is probably not what we want to do. But something similar to $viewChangeListeners, why not