The ability to reply to discussions is limited to PRO members. Want to join in the discussion? Click here to subscribe now.

Communicate State Changes in Angular with an Event Bus

Communicate State Changes in Angular with an Event Bus

2:49
In Angular 2, we use observables to push new data to our components. In Angular 1, we occasionally need to notify a component that a collection has changed so that we can perform an operation at the component level. For example, when we are editing or creating a bookmark, and we navigate to a new category, we are left in this awkward state of an incomplete edit. We need to be notified when a new category is selected at the bookmark level so that we can reset the current bookmark. Even though we do not have the convenience of an observable to emit state changes to us, we can still spin up an event bus to let us know when we need to hit reset.
Watch this lesson now
Avatar
egghead.io

In Angular 2, we use observables to push new data to our components. In Angular 1, we occasionally need to notify a component that a collection has changed so that we can perform an operation at the component level.

For example, when we are editing or creating a bookmark, and we navigate to a new category, we are left in this awkward state of an incomplete edit.

We need to be notified when a new category is selected at the bookmark level so that we can reset the current bookmark. Even though we do not have the convenience of an observable to emit state changes to us, we can still spin up an event bus to let us know when we need to hit reset.

Avatar
Przemysław

Does using rootscope as event bus is a good idea? Can this make a performance problemu? Broadcast is not a sample piple, mostly beacause It visit all scopes. It is not a problem in old aproach when you used mostly controllers and directives but know when everything is a component with own isolated scope. Or It is a problem but only in my head ;)

In reply to egghead.io
Avatar
Fabio Bedini

I agree with you,
I spent my money to learn all
best practice but this is not
the case :(

In reply to Przemysław
Avatar
Lukas

Hi Przemysław --
This is not a performance problem for a couple reasons...

First, state change is ALREADY being communicated via $scope through isolated scope bindings and optimized for it. Where this technique is necessary is when you need to communicate a state change that is NOT on $scope, i.e. model data. How do you tell the application that something has changed in service? How do you do this without coupling classes together? This is why the observer pattern exists and essentially what we are implementing.

Secondly, we are only broadcasting to container components so that they can update their presentation state which then gets propagated to the presentation components via isolated scope. So you are in part correct, this pattern is used to communicate JUST ENOUGH so that parallel container components can make the necessary adjustments and let component $scope take over.

Thirdly, this is a similar pattern to how Redux works in that instead of $rootScope.$broadcast, we have store.dispatch and instead of $scope.$on we have store.select and observables handle the eventing for us.

Fourthly, there are specific cases for using an event bus but $rootScope is the single BEST mechanism for the job. It has already been optimized to effectively communicate with every component within the application. How (or why) could we possibly roll something more efficient on our own?

Oh... one more... in this specific case... the frequency in which we are broadcasting is negligible in terms of performance considerations. If we were hooked up to a web socket that was broadcasting 100 times a second then I may reconsider my solution for that case.

In reply to Przemysław
Avatar
Lukas

Hi, Fabio - please see my answer above. If you know of a better way to communicate state mutations to parallel components that does not include tightly coupling classes together and involves a mechanism more efficient than $rootScope, I would be happy to consider it

In reply to Fabio Bedini
HEY, QUICK QUESTION!
Joel's Head
Why are we asking?