Hi Sander and Eric,
Here are my findings and solutions:
scope: {
model: '=',
switched: '&'
},
template: '<div model="alerts.volume.threshold" class="switch"
ng-click="toggle()"></div>',
link: function(scope, elem, attrs) {
scope.toggle = function() {
if (!scope.disabled) {
scope.model = !scope.model;
//setTimeout(function() {
scope.switched();
//});
}
};
}
My scope.model inside directive was bound by value despite that it is a
property inside a object inside an another object. So pass the line
scope.model = !scope.model only model in isolated scope was changed. And
then because there is watch on it due to its use in ng-class it was
updating the original proper in the controller, but after the digest loop
was done. My mistake or assumption was that binding scope.model
to "alerts.volume.threshold" would bind it by reference and of course that
right after scope.model = !scope.model line the original value is also
changed. When I bound to "alerts.volume object and just for testing
purposes would modify my line to scope.model.threshold =
!scope.model.threshold everything was as I expected it. But this is tight
coupling of course and this is no-no:)
The reason i used setTimeout and not $timeout is laziness to inject
$timeout in the rush of debugging.
Sander, regarding to $evalAsync it did not work when wrapped in single
quotes, but worked without them. But anyway the original value was still
bound to the old value inside my controller, with $timeout on the other
hand the value was bound to the new one.
Here is some summary about evalAsync and timeout differences from this qa
on stack overflow.com:
http://stackoverflow.com/questions/17301572/angularjs-evalasync-vs-timeout
To summarize:
- if code is queued using *$evalAsync from a directive*, it should run
*after* the DOM has been manipulated by Angular, but *before* the
browser renders
- if code is queued using *$evalAsync from a controller*, it should run
*before* the DOM has been manipulated by Angular (and before the browser
renders) -- rarely do you want this
- if code is queued using *$timeout*, it should run *after* the DOM has
been manipulated by Angular, and*after* the browser renders (which may
cause flicker in some cases)
Thank you all!!!
On Monday, May 26, 2014 8:30:11 AM UTC-7, Sander Elias wrote:
>
> Hi Eric,
>
> The doSomething was just a pseudo code example;) Nevertheless, it really
> does not matter if it takes a long time (if it is a really computing
> intensive task, it should be carried over to a web-worker!)
> Both the timeout and the asynceval set it to execute at a later time, but
> both do execute it, so there is no performance gain from either method.
> Both will add it at the end of the execution-chain.
> For performance (in a click handler!) its even better to not do a
> timeout/asynceval, as this is marginally adding load to the task. Either
> way, its hogging the execution-chain. All javascript will be executed
> before the next event gets processed.
> There is no escape from that. (well, other than the earlier named
> web-workers!)
> Usually one does not need to worry about those issues, Javascript is
> really fast nowadays. Unless traversing large amounts of data/DOM,
> performance is seldom an issue!
>
> Regards
> Sander
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
