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]>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]. > 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. > -- 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.
