Not really. You should be using services for all these cases. I would say that everything that you can do with `$rootScope` you can do with any other service as well. So there is no genuine use for `$rootScope` ( unless you are using it for other things like `$rootScope.$apply` ).
If you are using `$emit`, `$broadcast` and `$on` you are missing the whole beauty of angular. They (emit, broadcast etc! ) exist for a very specific purpose and there is a need for them in those cases. Basically, what I am trying to say is that - you should be using data-binding for 90-95% of the cases and the rest of the 5% cases are covered by the eventing mechanism. On Mon, Sep 15, 2014 at 3:53 PM, Otto Wong <[email protected]> wrote: > this has sparked another question regarding $rootScope. > > i've been using $rootScope.$emit, $rootScope.$on, and > $rootScope.$broadcast a lot, usually because i have weird cases where i > need to pass an object between different controllers, or perhaps i need an > event in one controller to trigger a function in another controller. > > based on what you've said, i'm guessing that if i'm injecting $rootScope > in all my controllers then it's a huge hit on performance.. > > i've also had a case where i needed one sibling controller to trigger a > function in another sibling controller, so i created a parent controller > for the two with the sole purpose of having a $scope.$on that simply just > had one line in it, and it was a $scope.$broadcast that triggered the > function in the other controller. > > are these acceptable ways of achieving what i need? > > > > On Monday, 15 September 2014 10:44:59 UTC-4, Otto Wong wrote: >> >> thanks for the suggestions Rishi.. i was searching on this topic for a >> long time and couldn't find anything that answered my question directly. >> changing the modal from a $rootScope function to a service will be a good >> exercise. >> >> On Mon, Sep 15, 2014 at 10:37 AM, Tandon, Rishi <[email protected] >> > wrote: >> >>> Otto, That's an excellent question. >>> Avoid injecting the model to $rootscope as that would increase >>> unnecessary overhead all over the app. Instead, create a reusable service >>> and use where it is needed. >>> The good candidates for $rootscope are: >>> 1. User Logged-in info. >>> 2. Device/ Browser/ Orientation detection >>> 3. httpSessionTimedOut global handler >>> 4. $routeChangeStart, $routeChangeSuccess & $routeChangeError global >>> handler >>> 5. Global app search >>> >>> Regards >>> Rishi Tandon >>> >>> On Mon, Sep 15, 2014 at 10:18 AM, Otto Wong < >>> [email protected]> wrote: >>> >>>> hi there.. i'm semi-new to angularjs, ie, i've been using it for a >>>> while now but i have no clue if what i'm building is against best practices >>>> or not! :) >>>> >>>> i'm coming to a point in my application where it's becoming apparent >>>> due to changes in requirements that certain features should have been done >>>> by creating a service, since multiple different places in the application >>>> are needing to do the same thing. >>>> >>>> a while back, i needed to open modals. this type of requirement is very >>>> easy to identify as "something that requires multiple places to do the same >>>> thing". back then, i was less familiar with services and factories and >>>> solved this problem by creating a function defined in the $rootScope, so >>>> every time i need to open a modal now, i include $rootScope in the >>>> controller that needs it and open it with a function that goes something >>>> like $rootScope.modal('open',url);, and close it with >>>> $rootScope.modal('close',''); >>>> >>>> is this way of doing it wrong or against best practices? i'd like to >>>> know if there is a performance difference between creating a service and >>>> just defining a lot of $rootScope functions? >>>> >>>> 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 [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. >>>> >>> >>> >>> >>> -- >>> *Rishi Tandon* >>> Pearson Learning Technology Group >>> >>> Mobile: (310) 926-9032 >>> >>> Pearson >>> Always Learning >>> Learn more at www.pearson.com >>> >>> -- >>> 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/TQxPxEzJzZQ/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. > -- Regards, Ganaraj P R -- 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.
