Add Angular1 Event Patterns/Best Practices

[jongunter]

It would useful if the Angular1 style guide could provide some opinionated patterns on $broadcast/$emit events. Looking at code samples all over the web, I see people doing things very differently. Questions that the guide might want to address:

• Naming: What's a good strategy for naming/namespacing events?
• When to use:: When is using these types of events a code smell? When is it advantageous?
• There's probably more, but I can't think of any right now...

I know a lot of these older event patterns are fading into the sunset in light of RxJs, Flux design patterns, and the like, but some of us still have to maintain "legacy" applications that use $broadcast and $emit.

Thanks. I don't know what I'd do without this style guide in my day-to-day Angular development! It's amazing. Just wanted to address a gap that I noticed.

[MarcLoupias]

When to use

TLDR : Never.

It is a highway for spaghetti source code.

Never ever use them. This is the best practice regardings events.

There is nothing you couldn't do with a service or a directive contract regarding events.

And more, using events means injecting $rootScope and $scope. It is by itself a bad practice.

[kylecordes]

We've (teaching classes) have been describing scope events as a pseudo-deprecated feature for a while now. It would be great for the Papa style guide to say something like that.

[jongunter]

Good to know. Thank you @MarcLoupias and @kylecordes .

Are there any articles/resources you'd recommend showing best practices for implementing common pub/sub patterns with services?

[kylecordes]

@jongunter I don't use AngularJS 1.x much anymore, but I do encounter large customer projects written in it. My advice for those projects as they try to forward to the most modern 1.x practices in preparation for a hopeful eventual move to Angular (2... 4... 5... 6...) is to pick up tools from their likely future and use those.

Your example of wanting to do pub/sub in the service fits that very nicely. Simply adopt RxJS, and use a Subject exposed one of your services. You can think of a Subject as (among many other things) a pub-sub channel ready to go in one line of code.

[kylecordes]

@jongunter Slightly relevant, I put this together for other purposes.

https://github.com/OasisDigital/angularjs-rxjs-example

(There is a link to a video in the README, that explains the code in depth.)

[mattgrande]

Can I ask a question of people advising against events? I have two components that need to talk to each other (eg, when you click on something in ComponentA, it needs to filter stuff in ComponentB). Currently, ComponentA fires an event that ComponentB listens to, but I agree, it's resulted in some hard-to-decipher code. How do you recommend handling situations like that?

[kylecordes]

Worthy of being considered a standard recommended style?

If the two components are closely adjacent (one is a parent of the other, or maybe they are siblings whose parent manages a feature that both of the components participate in), use ordinary data binding and event bindings to communicate among them.

If the two components are farther apart in the application, they can communicate most effectively by both injecting a service of some kind. That way the relationship between them is explicit and visible via the injection mechanism, rather than implicit based on commonly named events. Thi also avoids the "bucket brigade" that occurs if you use data binding an event binding to wire up far-flung components.

Beyond style guide scope

What kind of service should it be? I think that's far outside the scope of the style guide. I would typically say: it should be a reactive service, or in an app of some complexity, probably Redux or similar.