tengen tengen - 25 days ago 6
AngularJS Question

Pros/Cons of using events heavily to keep controllers in sync across complex Angular Apps

Can anyone give me some advice on the pros / cons of using events heavily to keep different parts of an Angular app in sync with each other?

I am considering using a series of events and event listeners to wire together an SPA with multiple concurrent and nested views, provided by Angular's ui-router. The layout of the SPA could be analogous to gmail, where there are logically separate regions of the screen (left area with list of mail folders, top navbar, main details view, etc).

I have been looking at ways to keep all the controllers in sync with regards to models they all need to access at the same time. When a model is updated by the top view, if some of that model is displayed in the main view, I want the main view to notice the change, and update its view accordingly.

I use services to share models across controllers, as is considered the best practice, but there are issues with that approach as discussed in depth in this question.

A possible solution to this is to use Angular's

$broadcast
and
.$on('event, fn())
to have controllers notice when a service they care about has updated data.

Problems:


  1. Using events to pass data instead of using services (tight coupling, ignoring any authoritative data source). I know you can pass object with events, but you don't have to.

  2. Performance (events bubble throughout $scope hierarchy, etc).

    $broadcast
    /
    $emit
    have performance and tight-coupling concerns that are covered a-plenty here and elsewhere, and I am considering using solution from an SO answer here to address performance / memory leaks from not cleaning up listeners when controllers are destroyed.

  3. Maintenance (spaghetti code / ignoring OO and just passing your entire app's model around in events).
    This is the main question I have for the community: based on the (ugly) diagram below, I imagine each angular
    .service
    firing an event when it gets updated model data, and any controllers who care about that data just listen for the event to fire:
    Event Wiring Diagram



It's actually simple to code (works now), but I worry about the 5-years-from-now headache of trying to keep track of all the event relationships.

Does anyone have any experience with a design like this, who can give me some advice on a smarter / more concise design?

Thanks in advance, and sorry for the crude diagram... hopefully its gets across the point.

Answer

Pros?

  • It makes angular more like Knockout/Durandal?

Cons?

  • It makes angular more like Knockout/Durandal?

I've answered one of the questions you linked: here So that might help you.

Which might also answer the question in your comment.

Also my advice is to not abandon OO. But embrace it, angular will then reward you by working all of the time.

Had you in the previosly linked question Had a User object with a password field you would have never had the issue Because the password would always have been reference-able through the user. And all of the bindings to User.password would have worked.

So only ever have one source of data. Keep that reference. And your two way binding will modify that data. You shouldn't have to worry about propagating it throughout your app in events.