There's an issue at GitHub trying to find solutions for asynchronous initialization: https://github.com/angular/angular.js/issues/5854 You might try to explain details of your requirement there.
On Wednesday, February 12, 2014 8:42:38 PM UTC+1, doug g wrote: > > Hi Tobias > > Thanks so much for your thoughtful reply. Now I understand the reason for > that $browser.defer, and it makes sense that you implemented it that way. > And you are right - Im not relying on the broadcast event, but rather the > deferred watchers, so the unit tests are more important to me. But Ill keep > an eye out for that kind of funkiness :-) > > Take care and be well. > > Yours, > Doug > > > On Wed, Feb 12, 2014 at 2:33 PM, Tobias Gesellchen > <[email protected]<javascript:> > > wrote: > >> Hi Doug, >> >> thanks for your feedback! >> >> It seems like the documentation for >> $browser<http://docs.angularjs.org/api/ng.$browser>is not linked on the >> table of contents and moreover doesn't contain any >> content. You can find a link at the $timeout >> documentation<http://docs.angularjs.org/api/ng.$timeout>under the section >> "Dependencies". $timeout uses $browser internally and >> you're right that we might have used an alternative service (like >> $timeout). I didn't check in detail, but I guess the documentation has >> changed since we wrote the code. Our blog >> article<http://blog-it.hypoport.de/2013/10/28/angularjs-ordered-init-async-promise/>also >> contained a deep link for the browser >> event >> loop<http://docs.angularjs.org/guide/scope#what-are-scopes_integration-with-the-browser-event-loop>to >> a currently missing section, which has been updated now. Regarding your >> question about the deprecation: only $defer has been deprecated in favor of >> $timeout, but $browser.defer is still available and not deprecated. Quite >> confusing :-) >> >> Finally about the background of why we wrapped the event broadcast in >> $browser.defer: >> I suggest you to read the details about the browser event >> loop<http://docs.angularjs.org/guide/scope#what-are-scopes_integration-with-the-browser-event-loop>first >> - it helps a bit understanding the Angular way of handling model >> changes. The relevant bit says that "the $digest loop keeps iterating >> until the model stabilizes, ...". You might now expect that the >> APPLICATION_INITIALIZED >> event would be broadcasted to all listeners inside the same $digest loop as >> the initialization promise chain. >> The listeners could probably update some model or trigger other actions, >> which depend on a completely initialized and stable model. But performing >> those actions inside the "app initializing loop" would risk that some >> details could be in a non initialized state. That's why we forced Angular >> to finish the "app initializing loop" and start a new $digest loop for the >> APPLICATION_INITIALIZED event. >> >> In most cases there won't be any problem with removing the $browser.defer >> call. As long as it works for you, the unit testing aspect is probably more >> relevant. We only had some edge case with route updates and backend calls >> which were not allowed to happen before the complete application had been >> initialized. So it depends on how much your initialized event listeners do. >> >> I hope your questions have been answered. Did I miss some detail or do >> you have any additional questions? >> >> Regards >> Tobias >> >> >> >> On Wednesday, February 12, 2014 3:31:27 PM UTC+1, doug g wrote: >>> >>> Hi >>> >>> First of all, thanks for your code example. I was running into the >>> problem of watchers being fired over and over on an app Im developing, and >>> your ordered initialization code helped a lot. >>> >>> Sorry for what is probably a newbie question, but I am looking at the >>> broadcastAppInitialized function, specifically using $browswer.defer for >>> setting initialized=true and broadcasting final initialization. For one, I >>> cant seem to find the documentation for $browser anywhere, and I even see a >>> post that suggests it might be deprecated (see >>> https://github.com/angular/angular.js/issues/532). Is there some hidden >>> documentation somewhere? >>> >>> Also, I tried changing the function to: >>> >>> var broadcastAppInitialized = function(){ >>> initialized = true; >>> $rootScope.$broadcast( APPLICATION_INITIALIZED ); >>> } >>> >>> (This makes unit testing a little easier as I dont have to mock >>> $browser.defer to set initialized=true) >>> >>> I can see no difference in how the code behaves using this simpler >>> method. Can I ask, what problem were you trying to solve by wrapping this >>> in the $browser.defer? >>> >>> Thanks >>> >>> Doug >>> >>> On Monday, October 28, 2013 6:55:44 AM UTC-4, Tobias Gesellchen wrote: >>>> >>>> Hi group, >>>> >>>> as already asked or suggested in several posts, you sometimes need to >>>> wait for http backend calls to finish before your AngularJS app is >>>> regarded >>>> as being initialized and usable. >>>> >>>> We also stumbled over the problem of $watch triggers or $on events >>>> being fired too early (before the http requests had been finished loading >>>> data) in the application lifecycle, so we have built a dedicated >>>> "initialization service" which enables us to configure the loading order >>>> of >>>> services and helps us configuring our controllers and $scopes to be >>>> initialized correctly. >>>> >>>> You can find a more thorough description at our >>>> blog<http://blog-it.hypoport.de/2013/10/28/angularjs-ordered-init-async-promise/>an >>>> a working demo at >>>> jsfiddle <http://jsfiddle.net/gesellix/xxKjw/>. >>>> >>>> We would like to get some feedback on our implementation. Please have a >>>> look at our code and provide some feedback in this group. Questions are >>>> welcome as well! >>>> >>>> Thanks! >>>> >>>> -- >> 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/6CxwIL4QSfY/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/angular. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- 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/groups/opt_out.
