Angular using callbacks vs using broadcast/emit/on paradigm

Question

My question is regarding best practices between using a more direct callback structure vs. event broadcasting and listening. I had not been using the broadcast/emit/on event propagation framework. Rather I had been creating a callback register and firing registered callbacks when a known event occurs (at the source of the event). This is all done via services.

How efficient is the broadcast/emit/on paradigm? Should I be using it instead? Is it as efficient as the callback type of structure?

Thanks.

Answer 1

It's less a question of efficiency but rather maintainability. When you use emit and broadcast you are coupling your mechanisms for communication to the view because the $scope is fundamentally a fabric for data-binding. The services approach is far more maintainable because you can test the communication without spinning up a scope and can communicate between services in addition to controllers. With $scope $broadcast and $emit you are only ever able to communicate where there is a $scope you can inject.

Answer 2

After more than a year of developing mobile applications with angular here is what I would say: It is not an issue of using services or not. It is an issue about what is the best way to design communication between your services and your controllers ( or other services ). In short, both callback or promise based communication AND event messaging have a role. Event messages are great if you are assured that the listener will be available to receive the message when it is broadcast. In general, event messages and event listeners "feel" like a cleaner and more maintainable paradigm. However, if I have a controller that is going to "request" some data from a service, I find resolution via Promises ( or callbacks if you prefer ) to be cleaner in those situations.