Provide $scope.$onRootScope method

[cburgdorf]

Many people are afraid of using angulars event mechanism as an EventBus as they fear of performance issues because of it's bubbling behavior.

However, those concerns don't apply if only $rootScope.$emit/ $rootScope.$on is used as there is no bubbling happening since $emit only bubbles upwards and there is no scope above the $rootScope.

I addressed this in my answer on the same thread.

In fact if eventing is used like that in an angular application than $rootScope is no different than the typical EventBus pattern. This comes with the drawback of manually having to unregister handlers from within controllers. Why that? Because controllers aren't singletons in Angular and therefore one needs to listen to the local $scope's $destroy event and then unregister from the event emitted by the $rootScope.

So controller code would look like this:

angular
    .module('MyApp')
    .controller('MyController', ['$scope', '$rootScope', function MyController($scope, $rootScope) {

            var unbind = $rootScope.$on('someComponent.someCrazyEvent', function(){
                console.log('foo');
            });

            $scope.$on('$destroy', unbind);
        }
    ]);

As stated in my SO post one can monkey patch the $rootScope to provide an alternative to it's $on method that takes an additional parameter with an $scope to listen for it's $destroy event to then do the deregistration for us.

 angular
    .module('MyApp')
    .config(['$provide', function($provide){
        $provide.decorator('$rootScope', ['$delegate', function($delegate){

            $delegate.$saveOn = function(name, listener, scope){
                var unsubscribe = $delegate.$on(name, listener);

                if (scope){
                    scope.$on('$destroy', unsubscribe);
                }
            };

            return $delegate;
        }]);
    }]);

With this in place we can subscribe to events emitted by the $rootScope and have them automatically deregistered when our local $scope is being destroyed.

We can use it like this:

angular
    .module('MyApp')
    .controller('MyController', ['$scope', '$rootScope', function MyController($scope, $rootScope) {

            $rootScope.$saveOn('someComponent.someCrazyEvent', function(){
                console.log('foo');
            }, $scope);
        }
    ]);

However, I think we could do much better by providing a $onRootScope method directly on the Scope type so that it's available on every $scope. This would then automatically make the deregistration for us but we wouldn't have to pass the $scope explicitly.

It would simply look like this.

angular
    .module('MyApp')
    .controller('MyController', ['$scope', function MyController($scope) {

            $scope.$onRootScope('someComponent.someCrazyEvent', function(){
                console.log('foo');
            });
        }
    ]);

As far as I know, I can't monkey patch that directly.

Shamelessly pulling @IgorMinar @mhevery @btford and @petebacondarwin and @matsko into this issue ;-)

[petebacondarwin]

I would rather provide a custom eventBus service that does this for us than
adding new stuff to rootScope. This would be more self documenting.
On 22 Oct 2013 09:46, "Christoph Burgdorf" notifications@github.com wrote:

Many people are afraid http://stackoverflow.com/a/12015847/288703 of
using angulars event mechanism as an EventBus as they fear of performance
issues http://stackoverflow.com/a/12015847/288703 because of it's
bubbling behavior.

However, those concerns don't apply if only $rootScope.$emit/
$rootScope.$on is used as there is no bubbling happening since $emit only
bubbles upwards and there is no scope above the $rootScope.

I addressed this in my answer on the same threadhttp://stackoverflow.com/a/19498009/288703
.

In fact if eventing is used like that in an angular application than
$rootScope is no different than the typical EventBus pattern. This comes
with the drawback of manually having to unregister handlers from within
controllers. Why that? Because controllers aren't singletons in Angular and
therefore one needs to listen to the local $scope's $destroy event and
then unregister from the event emitted by the $rootScope.

So controller code would look like this:

angular
.module('MyApp')
.controller('MyController', ['$scope', '$rootScope', function MyController($scope, $rootScope) {

        var unbind = $rootScope.$on('someComponent.someCrazyEvent', function(){
            console.log('foo');
        });

        $scope.$on('$destroy', unbind);
    }
]);

As stated in my SO post one can monkey patch the $rootScope to provide an
alternative to it's $on method that takes an additional parameter with an
$scope to listen for it's $destroy event to then do the deregistration
for us.

angular
.module('MyApp')
.config(['$provide', function($provide){
$provide.decorator('$rootScope', ['$delegate', function($delegate){

        $delegate.$saveOn = function(name, listener, scope){
            var unsubscribe = $delegate.$on(name, listener);

            if (scope){
                scope.$on('$destroy', unsubscribe);
            }
        };

        return $delegate;
    }]);
}]);

With this in place we can subscribe to events emitted by the $rootScopeand have them automatically deregistered when our local
$scope is being destroyed.

We can use it like this:

angular
.module('MyApp')
.controller('MyController', ['$scope', '$rootScope', function MyController($scope, $rootScope) {

        $rootScope.$saveOn('someComponent.someCrazyEvent', function(){
            console.log('foo');
        }, $scope);
    }
]);

However, I think we could do much better by providing a $onRootScopemethod directly on the
Scope type so that it's available on every $scope. This would then
automatically make the deregistration for us but we wouldn't have to pass
the $scope explicitly.

It would simply look like this.

angular
.module('MyApp')
.controller('MyController', ['$scope', function MyController($scope) {

        $scope.$onRootScope('someComponent.someCrazyEvent', function(){
            console.log('foo');
        });
    }
]);

Shamelessly pulling @IgorMinar https://github.com/IgorMinar @mheveryhttps://github.com/mhevery
@btford https://github.com/btford and @petebacondarwinhttps://github.com/petebacondarwinand
@matsko https://github.com/matsko into this issue ;-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4574
.

[cburgdorf]

@petebacondarwin I'm not really sure. Then you would have events in two different places and you would always have to decide whether you want it to be this way or that way. If you later on decide that an event should bubble down the scope hierarchy, you would have to move it from the eventBus to the $rootScope. On the other hand, I think the bubbling is only beneficial for events that are not application wide. I don't see a reason why things like $locationChangeSuccess should bubble down the scopes. It's an application wide event it should just be raised on the EventBus (whether it be $rootScope or $eventBus) and if you want to listen to it, you would subscribe just their on the EventBus.

The only benefit of the bubbling currently is that you don't have to care about cleaning up the handler as that's automatically done for you when your local $scope gets destroyed. However, that's exactly what would also be solved by my $scope.$onRootScope proposal.

So when you say you would rather have a seperate $eventBus implementation, would you agree that things like $locationChangeSuccess should rather go their so that they don't bubble anymore? If so, how would you handle the deregistration of handlers? If it's not something cleanly built in, people will create memory leaks all over the place. Or would you still use a $scope.$onEventBus then to have automatic deregistration when your local scope gets destroyed?

[ajoslin]

You can do the decorator more easily:

$provide.decorator('$rootScope', ['$delegate', function($rootScope) {
  $rootScope.prototype.$onRootScope = function(eventName, callback) {
    var unbind = $rootScope.$on(eventName, callback);
    this.$on('$destroy', unbind);
  });
});

The scopes will inherit the $onRootScope method, and now any scope can do $scope.$onRootScope().

I guess this would enhance performance in some situations ... but doesn't seem like a new method in core is the right way to do it.

[cburgdorf]

@ajoslin oh man, I didn't see the forest for the trees :) Great to see it's possible with the decorator. However, I really think this should be addressed in core. I think this should be the default for application wide events, no? Can you come up with any scenario where it's actually beneficial that $locationChangeSuccess does bubble down all the scopes? If it would just $emit on the $rootScope and everyone would just use $onRootScope to subscribe to such application wide events, we would all benefit from faster events without giving up on auto resource cleaning.

[wesleycho]

I've found in my experience that you should only be using $emit/$broadcast sparingly, since using it instead of $watch becomes harder to maintain (plus ends up being quite more verbose). My only good use case has been to handle when a particular piece of DOM has been rendered.

As for $locationChangeSuccess, it may be possible you may want to have your logic dependent on the $scope hierarchy, and potentially execute depending on the order it comes in if it isn't prevented somewhere along the tree.

Modifying the core of $rootScope to accomplish your purpose doesn't feel right though.

[cburgdorf]

@wesleycho I heard this claim before but I'm not ready to give up on event based architecture yet. We are in the process of building a SDK for www.couchcommerce.org. The SDK enables you to write web apps that run on our CouchCommerce platform. All of our core functionality is accessible by client side services that don't have any dependencies on Angular. We have an angular specific build though that wraps those services into modules and module.factory() to make them accessible with angular's DI.

Let's take something like a basketService. In it's current implementation it raises events like itemAdded, itemRemoved etc that you can subscribe to to invoke further actions or manipulate the UI etc. One of the core philosophies behind our SDK is that it works great with any framework (while explicitly providing further assistance if you pick angular as your framework of choice) may it be jquery-mobile, emberjs or AngularJS. Since not every framework has something like angular's $watch, raising events from within services to react up on from within controllers really works well for us.

Currently we raise events directly on the services their selves (our framework brings it's very lightweight own pub/sub mechanism) but we further plan to use a dedicated eventBus to raise events on. Since our whole library is built around the idea of dependency injection, we can simple inject the eventBus in all services which need to raise events. Thinking this a step further we could replace that eventBus with angular's $rootScope for the angular build of our SDK. So everyone who uses our SDK + angular gets angular's built in eventBus ($rootScope) whereas all others who choose something different (e.g. SDK + jquery-mobile) get our own implementation of the eventBus. Of course both implementations need to share the same interface or work through adapters though. However, this way our SDK doesn't feel alien to angular devs as all events will just be emitted on the $rootScope and furthermore they save bytes as we don't need to deliver our own eventBus implementation for those folks who use the SDK + angular.

This might be a very special use case but at least I hope i was able to provide some insights on why I'm not ready to give up on events as the main communication channel :)

[cburgdorf]

@ajoslin I had to roll back your edit in that SO post as $delegate.prototype isn't available to patch. That was why thought it wouldn't be possible to monkey patch at all.

[cburgdorf]

@ajoslin fixed it so that it now works together with isolated scopes, too. It has to be:

 angular
    .module('MyApp')
    .config(['$provide', function($provide){
        $provide.decorator('$rootScope', ['$delegate', function($delegate){

            $delegate.constructor.prototype.$onRootScope = function(name, listener){
                var unsubscribe = $delegate.$on(name, listener);
                this.$on('$destroy', unsubscribe);
            };

            return $delegate;
        }]);
    }]);

[btford]

Shamelessly pulling @IgorMinar @mhevery @btford and @petebacondarwin and @matsko into this issue ;-)

^ FYI, this tactic will not get your issue more attention (and if it did, soon everyone would be using this "trick" and it would quickly become useless). We do our best to look at each issue already. Please don't do this in the future.

[cburgdorf]

aye aye, sir!

What do you think about the issue itself? Considering how many CPU cycles are wasted by people using $rootScope.$broadcast + $scope.$on I don't see why we shouldn't give them an $onRootScope method so that they can replace that pattern with the faster $rootScope.$emit + $scope.$onRootScope pattern.

[btford]

Considering how many CPU cycles are wasted

I'd be curious to see a benchmark of the difference. I think a separate service might be better, but I'm not convinced that this is that much cheaper than broadcasting on $rootScope. I suspect a digest is the expensive part, and you aren't avoiding that with this approach.

[cburgdorf]

This very much depends on how many scopes you have on your page. I try to come up with a jsperf over the next days :)

[cburgdorf]

Hey @btford I put together a simple jsperf that compares the perf differences between $broadcast and $emit on a decent scenario with 100 scopes.

Here is the link to the perf

[cburgdorf]

Just do add another thought here. I know that event handling in Angular is somewhat designed around the idea of browser events. Just I wonder if global events like (window) load, hashchange etc bubble downwards through the entire DOM tree? As far as I know they don't.

You can fiddle with the hashchange event here on quirksmode for instance and it doesn't seem to bubble down.
http://www.quirksmode.org/dom/events/tests/hashchange.html

I have a hard time finding use cases for $broadcast honestly. I understand that such fundamental things shouldn't be changed before 1.2 but I propose to change them afterwards. By promoting this $rootScope.$broadcast pattern all kinds of 3rd party libraries also use it and you end up with lot's of events flowing from $rootScope through the entire scope tree. I have bad feelings about that.

[caitp]

Currently, every $scope event 'bubbles' upwards or downwards unless stopPropagation is called...

I was thinking that it would be useful to be able to ask the event not to bubble (via a parameter or a separate function call).

Since the code for $emit and $broadcast is very similar, we could also shrink the code a bit by having a single function performing most of the work, and using closures to customize the behaviour slightly for each. Using this strategy (similar to jQuery's event dispatch mechanism), it could be simple to prevent an event from bubbling, and also simplify maintenance in the future.

This is kind of off topic for this issue, but I think it's probably a good idea, even if it introduces some minor breaking changes