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 the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to angular+unsubscr...@googlegroups.com. To post to this group, send email to angular@googlegroups.com. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out.
