Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

EventEmitter in angular services, good or bad?

Tags:

I was using EventEmitter and @Output in Angular services, today one of the colleagues mentioned it's not a good practice.

I found this post mentioning it's a bad practice and it seems mostly is personal opinion, and this answer is mentioning it's OK to use it. I couldn't find any official document about it, so if somebody knows an official answer for it please post.

Official doc about EventEmittter

like image 416
Reza Avatar asked Jun 01 '18 16:06

Reza


People also ask

Should I use EventEmitter or subject?

Conclusion. Use Eventemitter when transferring data from child component to parent component. Use Subject to transfer data from one component to another component.

Why EventEmitter is used in Angular?

What Is EventEmitter in Angular. EventEmitter is a module that helps share data between components using emit() and subscribe() methods. EventEmitter is in the Observables layer, which observes changes and values and emits the data to the components subscribed to that EventEmitter instance.

Why do we need EventEmitter?

The EventEmitter class can be used to create and handle custom events module. Default Value: false It automatically captures rejections. Listening events: Before emits any event, it must register functions(callbacks) to listen to the events.


1 Answers

I was using EventEmitter and @Output in Angular services, today one of the coleagues mentioned it's not a good practice.

The annotation @Output() has no effect in a service. It is used to tell the Angular template compiler to bind an Observable to a template expression.

If I saw @Output() in a service, then I'd tell the developer to remove it.

EventEmitter is an Observable and there are no side effects in using it in a service, but there are also no benefits.

You can use any Observable type of emitter in either a component or service. There are two reasons why we have EventEmitter. 1) it pre-dates the Angular teams decision to commit to using observables and they thought they might need their own implementation, 2) it can emit values in the next JavaScript cycle (optional setting).

There were edge cases were people needed to emit changes in the next cycle to avoid problems with change detection.

Secure Your Observables

 @Injectable()
 export class MyService {
       public events: Subject<any> = new Subject();
 }

The problem with the above service is that anyone can emit values from the public events. You want your service to be the only code that handles emitting values.

 @Injectable()
 export class MyService {
       private _events: Subject<any> = new Subject();
       public get events(): Observable<any> {
           return this._event.asObservable();
       }
 }

The above is better because access to the Subject.next(..) is private. Consumers can only subscribe to the observable.

If you followed the components approach. It forces you to expose your emitter which isn't a good idea.

@Injectable()
export class MyService {
       @Output()   // <<< has no effect
       public events: EventEmitter<any> = new EventEmitter();
       // ^^ makes the emitter public
}

Components need to have their properties as public if they are to be used in templates, but this isn't the case for services.

like image 142
Reactgular Avatar answered Sep 28 '22 18:09

Reactgular