Home » Angularjs » $rootScope.$broadcast vs. $scope.$emit

$rootScope.$broadcast vs. $scope.$emit

Posted by: admin November 2, 2017 Leave a comment

Questions:

Now that the performance difference between $broadcast and $emit has been eliminated, is there any reason to prefer $scope.$emit to $rootScope.$broadcast?

They are different, yes.

$emit is restricted to the scope hierarchy (upwards) – this may be good, if it fits your design, but it seems to me a rather arbitrary restriction.

$rootScope.$broadcast works across all that choose to listen to the event, which is a more sensible restriction in my mind.

Am I missing something?

EDIT:

To clarify in response to an answer, the direction of the dispatch is not the issue I’m after. $scope.$emit dispatches the event upwards, and $scope.$broadcast – downwards. But why not always use $rootScope.$broadcast to reach all the intended listeners?

Answers:

tl;dr (this tl;dr is from @sp00m‘s answer below)

$emit dispatches an event upwards … $broadcast dispatches an event downwards

Detailed explanation

$rootScope.$emit only lets other $rootScope listeners catch it. This is good when you don’t want every $scope to get it. Mostly a high level communication. Think of it as adults talking to each other in a room so the kids can’t hear them.

$rootScope.$broadcast is a method that lets pretty much everything hear it. This would be the equivalent of parents yelling that dinner is ready so everyone in the house hears it.

$scope.$emit is when you want that $scope and all its parents and $rootScope to hear the event. This is a child whining to their parents at home (but not at a grocery store where other kids can hear).

$scope.$broadcast is for the $scope itself and its children. This is a child whispering to its stuffed animals so their parents can’t hear.

Questions:
Answers:

They are not doing the same job: $emit dispatches an event upwards through the scope hierarchy, while $broadcast dispatches an event downwards to all child scopes.

Questions:
Answers:

I made the following graphic out of the following link: https://toddmotto.com/all-about-angulars-emit-broadcast-on-publish-subscribing/

Scope, rootScope, emit, broadcast

As you can see, $rootScope.$broadcast hits a lot more listeners than $scope.$emit.

Also, $scope.$emit‘s bubbling effect can be cancelled, whereas $rootScope.$broadcast cannot.

Questions:
Answers:

enter image description here

$scope.$emit: This method dispatches the event in the upwards direction (from child to parent)

enter image description here
$scope.$broadcast: Method dispatches the event in the downwards direction (from parent to child) to all the child controllers.

enter image description here
$scope.$on: Method registers to listen to some event. All the controllers which are listening to that event get notification of the broadcast or emit based on
the where those fit in the child-parent hierarchy.

The $emit event can be cancelled by any one of the $scope who is listening to the event.

The $on provides the “stopPropagation” method. By calling this method the event can be stopped from propagating further.

Plunker :https://embed.plnkr.co/0Pdrrtj3GEnMp2UpILp4/

In case of sibling scopes (the scopes which are not in the direct parent-child hierarchy) then $emit and $broadcast will not communicate to the sibling scopes.

enter image description here

For more details please refer to
http://yogeshtutorials.blogspot.in/2015/12/event-based-communication-between-angularjs-controllers.html

Questions:
Answers:

@Eddie has given a perfect answer of the question asked.
But I would like to draw attention to using an more efficient approach of Pub/Sub.

As this answer suggests,

The $broadcast/$on approach is not terribly efficient as it broadcasts to all the scopes(Either in one direction or both direction of Scope hierarchy). While the Pub/Sub approach is much more direct. Only subscribers get the events, so it isn’t going to every scope in the system to make it work.

you can use angular-PubSub angular module. once you add PubSub module to your app dependency, you can use PubSub service to subscribe and unsubscribe events/topics.

Easy to subscribe:

// Subscribe to event
var sub = PubSub.subscribe('event-name', function(topic, data){

});

Easy to publish

PubSub.publish('event-name', {
    prop1: value1,
    prop2: value2
});

To unsubscribe, use PubSub.unsubscribe(sub); OR PubSub.unsubscribe('event-name');.

NOTE Don’t forget to unsubscribe to avoid memory leaks.

Questions:
Answers:

Use RxJS in a Service

What about in a situation where you have a Service that’s holding state for example. How could I push changes to that Service, and other random components on the page be aware of such a change? Been struggling with tackling this problem lately

Build a service with RxJS Extensions for Angular.

<script src="//unpkg.com/angular/angular.js"></script>
<script src="//unpkg.com/rx/dist/rx.all.js"></script>
<script src="//unpkg.com/rx-angular/dist/rx.angular.js"></script>
var app = angular.module('myApp', ['rx']);

app.factory("DataService", function(rx) {
  var subject = new rx.Subject(); 
  var data = "Initial";

  return {
      set: function set(d){
        data = d;
        subject.onNext(d);
      },
      get: function get() {
        return data;
      },
      subscribe: function (o) {
         return subject.subscribe(o);
      }
  };
});

Then simply subscribe to the changes.

app.controller('displayCtrl', function(DataService) {
  var $ctrl = this;

  $ctrl.data = DataService.get();
  var subscription = DataService.subscribe(function onNext(d) {
      $ctrl.data = d;
  });

  this.$onDestroy = function() {
      subscription.dispose();
  };
});

Clients can subscribe to changes with DataService.subscribe and producers can push changes with DataService.set.

The DEMO on PLNKR.