32

I've been reading up on event passing in Angularjs and I'm not convinced that using $broadcast is a good idea.

Blogs like this one advocate getting used to $on even though it "felt like overkill."

My confusion is that the implementation uses a depth-first traversal of the scopes and looks for subscribers, which makes the speed of your events dependent on your tree structure. Here is some code from that in angular:

// Insanity Warning: scope depth-first traversal
// yes, this code is a bit crazy, but it works and we have tests to prove it!
// this piece should be kept in sync with the traversal in $digest
if (!(next = (current.$$childHead || (current !== target && current.$$nextSibling)))) {
   while(current !== target && !(next = current.$$nextSibling)) {
     current = current.$parent;
   }
}

Additionally, it seems like you would be able to hack dependency injection using these methods.

The alternative is simply a service that caches event types and callbacks, and calls them directly. This requires that you clean up the subscriptions to avoid leaks.

My question is, is there anything I'm missing about the motivation for the $broadcast/$on paradigm? Or is there any benefit to use it over a more traditional pubsub?

Let me know if I'm not being clear enough with my question, and thanks for your time.

hassassin
  • 5,024
  • 1
  • 29
  • 38

2 Answers2

19

I don't think you are missing anything. You've successfully outlined the pros/cons of each approach.

The $broadcast/$on approach doesn't require you to unsubscribe, but it is not terribly efficient as it broadcasts to all the scopes. It also has a very low barrier to entry. You don't need to inject any services, you don't need to create them. They broadcast to everyone, so it is a more simple approach.

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. It is more complex, however, because you need to write your service with callback handlers, and you have to remember to unsubscribe. The remembering to unsubscribe is pretty huge in my opinion. If you don't get this right, you get memory leaks. And you won't know it until it is a problem in 3 months.

I can see why the built-in approach is $broadcast.

Brian Genisio
  • 47,787
  • 16
  • 124
  • 167
  • 1
    I wonder if there isn't a way to automatically unsubscribe. If a pub/sub model was integrated with angular, you could automatically unsubscribe on `$destroy`. Controllers and directives usually correspond to a scope and could unsubscribe on its destroy in a pretty `1::1` way. Services/factories/providers are less obvious to automate, but usually they are singletons anyway. – SimplGy Feb 13 '14 at 18:11
  • You could do something like that, but then you would be passing scopes to a service. This seems like not the best practice. – hassassin Feb 17 '14 at 05:26
  • 1
    Personally, I don't have a huge issue with passing `$rootScope` into services. I understand the visceral reaction, but the pragmatist in me says "why not?". – Brian Genisio Feb 19 '14 at 01:55
  • Passing the `$rootScope` is not enough. That allows you to destroy all pub subs when the $rootScope is destroyed, but you would need to pass in individual `$scope` objects. The reason to not do this is because services should be agnostic of the hierarchy. In this case it's still pretty safe to do that, but I like it as a steadfast rule. – hassassin Mar 03 '14 at 22:17
  • `$broadcast` doesn't necessarily "broadcast" to everyone. It only sends events to a Scope's children scopes. `$rootScope.$broadcast` will send to "everyone," but a controller's `$scope.$broadcast` will only send to controllers and directive scopes contained within that controller. – m.e.conroy May 12 '14 at 13:51
  • @BrianGenisio My problem with `$rootScope` for services is that it hides the underlying connection between them. For a controller-controller communication, it is more acceptable since you can't inject a controller as a dependency. For a service, however, it is perfectly reasonable to require the "publishing" service as a dependency, and call a specialized function on that service to subscribe. That allows you to easily see a relation between subscriber-publisher, unlike the cryptic $on("some-string") callback in which the source can be anything and anyone. – VitalyB Aug 26 '14 at 07:21
  • Hi. I'm the author of angular-ms (https://github.com/ejmarino/angular-ms) project. It's a Messaging service base on pub/sub design pattern. Hope you can take a look. – Emiliano Jun 10 '15 at 20:58
2

I was looking at this same problem. Particularly how to allow services to broadcast and subscribe to events without accessing $rootScope (bad for a few reasons). I utilized the very excellent js-signals implementation from here : http://millermedeiros.github.io/js-signals/ and wrapped it into an angular service.

github gist here : https://gist.github.com/anonymous/b552c7fafa77427e6d06

rushkeldon
  • 1,343
  • 1
  • 10
  • 13