Communication in an angular app – two approaches

Nowdays it is clear that web apps must be modular.  Each module has to be able to “talk” to other modules and notify them on data change. How to do that without causing scope spaghetti and memory leaks?

The main idea is to prevent long term objects (such as services) from holding short term related objects/functions (such as directive controller methods). Why? Because directives can be switched on and off without much thought (ng-if to name one such method).

Here are 2 ways to do it – one is a sync way and another is async:

The async method exposes a promise from the service that is notified every time it needs to.

The sync method allows the directive to hook to some event in the service, and then the ability to unhook it when the directive is destroyed.

Both would activate the needed methods in the directive (click on “code” above and choose the “app.js” in order to see the code).  When you click the “Do Something” button, the controller would activate some method in the service, but you could imagine a call to the server and data that’s coming in – without involving the controller at all. Look at the console to see the resulting logs.  You can play with it and try some more advanced use cases (console.log is not the most useful UI method :)).

These are 2 simple methods in which you could avoid memory leaks while maintaining connectivity within your app.

Edit 3/7/2016: I’ve noticed that the promises were left untouched in the $destroy event. This would cause a memory leak if not taken care of.  It has been fixed in the plnkr itself.  The async setter now returns a method that destroys the relevant callback.

3 thoughts on “Communication in an angular app – two approaches

    • Yonatan Post author

      Hi Ram,
      Heres’ the answer for your question:
      The sync method would run, well… synced :). Now seriously, it will run in the same loop one after the other. This would cause one error in only one method to stop the whole procedure from the point of the error. – so if you have 10 listeners, and the 4th have an error, 3 would run, the rest would not.
      With the async method, each “notification” is independent of the others, so one error does not stop the rest. Taking the 10 listeners example from above, you will have 9 methods that would run, and one with an error.
      There’s no right and wrong here – it quite depends on the wanted behavior. You’d might want to be more strict (sync) or allow a certain error to pass while letting the rest of the app keep going (async).

Leave a Reply