Agreed that template bindings are preferable to directly watching where
possible, but that's not always the case. For one-time initialization you
can (and should) defend against the watcher getting called again by
removing it:
var unwatch = scope.$watch('key', function (val) {
if (!val) {
return;
}
unwatch();
...
});
On Wed, Aug 5, 2015 at 11:22 AM, Stewart Mckinney <[email protected]>
wrote:
> The reason why this works is because ng-repeat uses $watchCollection
> internally to render its elements - this happens after your ( pre )link
> function. ( It effectively inserts a $compile step after linking ).
>
> So if you wait for a $digest, you ensure that $watchCollection fires,
> which means you get your DOM.
>
> There are some other ways to get around this. In this past I have done
> really simple things like using $last with ng-repeat to render a
> conditional element that simply fires an event on ng-init ( not the
> cleanest but the fastest if you don't want a custom directive ) or use a
> custom directive to fire an event in it's link function. You can also just
> access the parent controller via require and fire some init function in
> link, or just be very straightforward and move the third-party
> initialization into the custom directive's link function ( typically
> requiring it wrapped in an angular service ), avoiding the need for events,
> timeout, or require.
>
>
> I don't think that using $watch is a great idea. In general I try to stay
> away from using it directly - template bindings will often give me all I
> need. Using a feature which is meant to be used as an observer function in
> conjunction with model changes once for initialization purposes is asking
> for trouble in my opinion. I would worry, for instance, about that $watch
> firing twice and a third party JS library not being idempotent.
>
>
> There was some talk about having an "afterDigestLoop" event for Angular (
> I forget the name of it , but there is a github issue open ), that would
> fire after $digest completely finishes that would be useful in a case like
> this.
>
>
>
> On Wed, Aug 5, 2015 at 10:31 AM, Kevin Shay <[email protected]> wrote:
>
>> If $timeout(..., 0) works in your case, then I agree that it's OK to use,
>> but I still think $watch() is the more idiomatic way of doing this.
>> Presumably in your finished application the data won't be hardcoded into
>> the controller; if it's coming from an asynchronous HTTP request, then
>> you'll have to set the timeout delay to some
>> hopefully-long-enough-but-not-so-long-it-slows-down-the-UI number of
>> milliseconds. With $watch(), Angular will take care of notifying your code
>> when the data is loaded and the variables are populated.
>>
>> Basically, I think the rule of thumb is that using $timeout with a 0
>> delay to wait for the digest cycle to finish is fine, whereas using it with
>> a fudge-factor value to wait for something asynchronous should be
>> considered a hack, albeit one that's sometimes necessary when dealing with
>> libraries external to Angular.
>>
>> Kevin
>>
>> On Wed, Aug 5, 2015 at 3:42 AM, Sander Elias <[email protected]>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>>> Am I correct in assuming that the reason $timeout works is because it
>>>> puts the closure at the end of the event loop queue so that all of the
>>>> angular binding functions have fired before the $timeout function is
>>>> executed?
>>>>
>>> That is indeed the case. It makes sure there is at least 1 $digest loop
>>> <https://www.ng-book.com/p/The-Digest-Loop-and-apply/> finished.
>>>
>>> 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.
>>>
>>
>> --
>> 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.
>>
>
> --
> 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.
>
--
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.
