Stewart. Thanks for the detailed response. One thing, though. "...or just be very straightforward and move the third-party initialization into the custom directive's link function.." -- I believe this is exactly what I tried and it didn't work because the bound expressions hadn't been resolved (or whatever the term is) yet.
Yeah, I'm surprised there isn't an "afterDigestLoop" event. Seems like something that would come up a lot. Thanks, Andrew On Wed, Aug 5, 2015 at 9: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 a topic in the > Google Groups "AngularJS" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/angular/x_BTRTKa2fo/unsubscribe. > To unsubscribe from this group and all its topics, 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.
