Hi Tobias Happy to support the community that way, but can you give me a few more details about what you might be looking for from that? My requirements were actually not much more than an ordered and controlled initialization process, and a way to avoid triggering multiple $watches. Your solution does both quite well
Doug On Tue, Feb 18, 2014 at 2:33 PM, Tobias Gesellchen <[email protected]>wrote: > 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]>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 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.
