-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Onchange is getting triggered before the model update for isolate scope #4558
Comments
Interesting corner case ... http://plnkr.co/edit/lsrga8qMcbgNWATrVht3?p=preview This happens only when the onChange function is delegated to the parent scope width the '&' binding. |
We have been working on a RAD tool based on angularjs. Have a look at : https://studio.wavemaker.com/ Regards, Vinay |
Could you post an example of this proxy and how it is used? Might help in debugging this. |
See the example at: http://plnkr.co/edit/Xe6ErQrg7WL6aAIoM9Gd?p=preview |
Will it be fixed anytime soon? It is sooooo confusing. |
After further consideration, I have to say that this is expected behavior.. In the plnkr example, the value of the ngModel is a two bound string between the controller and the directive scope. Now when you are changing the value in the directive, ngModel will update the isolate scope first, and fire the ngChange in the same digest. Since the two-way binding hasn't yet picked up a change to the directive scope, the ngChange in the parent scope gets the "old" value of |
Narretz, I strongly disagree. There is a contract made with the developer consuming the code that the two-way binding takes precedence. When a change is made anywhere along the chain of binding, the entire chain should be updated before continuing. So even if another directive inherits from this directive, and something further down binds to a binding of a binding... if that model is updated, the original controller scope model at the bottom of the stack should be updated in the same digest cycle before continuing on to other functions. It's what is expected from the consumer. |
Slightly related, and likewise confusing. When using Using Example: regards, Jakob |
Are there any plans to revisit this issue? Perhaps reopen? I ran into this issue and reading through the comments, while the way it currently works due to the isolate scope makes sense; the outcome that comes from expecting an updated model when the on-change call fires and getting the model one iteration previous definitely is not the behavior you expect as a developer. |
I adhere to the question, is this gonna be revisited? |
I don't think so. The current behavior is expected and although it is not desirable in some cases, there are at least as many cases where it is. Changing it now would (a) be a breaking change and (b) make many usecases unsupported (e.g. where you want
The current implementation of As already mentioned, if your specific callback needs access to the updated value, there are a few options:
.directive('myAsyncChange', function($timeout) {
return {
restrict: 'A',
require: 'ngModel',
link: function(scope, element, attr, ctrl) {
ctrl.$viewChangeListeners.push(function() {
$timeout(function() {
scope.$eval(attr.myAsyncChange);
});
});
}
};
}); <input ng-model="foo" my-async-change="onChange()" /> |
Onchange event for the elements having isolate scope is getting triggered before the model update.
Example:
The text was updated successfully, but these errors were encountered: