He leído preguntas como Access EventEmitter Service dentro de CustomHttp donde el usuario usa EventEmitter en su servicio, pero en este comentario se le sugirió que no lo usara y usara Observables directamente en sus servicios.

También leí esta pregunta donde la solución sugiere pasar el EventEmitter al niño y suscribirse a él.

Mi pregunta es: ¿debería o no debería suscribirme manualmente a un EventEmitter? ¿Cómo debo usarlo?

TL; DR :

No, no se suscriba manualmente a ellos, no los use en los servicios. Úselos como se muestra en la documentación solo para emitir eventos en los componentes. No vencer la abstracción angular.

Responder:

No, no debes suscribirte manualmente.

EventEmitter es una abstracción angular2 y su único propósito es emitir eventos en componentes. Citando un comentario de Rob Wormald

[...] EventEmitter es realmente una abstracción angular, y debe usarse prácticamente solo para emitir eventos personalizados en componentes. De lo contrario, solo use Rx como si fuera cualquier otra biblioteca.

Esto se afirma realmente claro en la documentación de EventEmitter.

Uso por directivas y componentes para emitir eventos personalizados.

¿Qué hay de malo en usarlo?

Angular2 nunca nos garantizará que EventEmitter continuará siendo un Observable. Eso significa refactorizar nuestro código si cambia. La única API a la que debemos acceder es su emit()método. Nunca debemos suscribirnos manualmente a un EventEmitter.

Todo lo mencionado anteriormente es más claro en el comentario de Ward Bell (recomendado para leer el artículo y la respuesta a ese comentario). Citando para referencia

¡NO cuente con que EventEmitter continúe siendo un Observable!

¡NO cuente con que los operadores Observables estarán allí en el futuro!

Estos serán obsoletos pronto y probablemente eliminados antes del lanzamiento.

Use EventEmitter solo para el enlace de eventos entre un componente secundario y uno primario. No te suscribas a él. No llame a ninguno de esos métodos. Solo llamareve.emit()

Su comentario está en línea con el comentario de Rob hace mucho tiempo.

Entonces, ¿cómo usarlo correctamente?

Simplemente utilícelo para emitir eventos desde su componente. Eche un vistazo al siguiente ejemplo.

@Component({
    selector : 'child',
    template : `
        <button (click)="sendNotification()">Notify my parent!</button>
    `
})
class Child {
    @Output() notifyParent: EventEmitter<any> = new EventEmitter();
    sendNotification() {
        this.notifyParent.emit('Some value to send to the parent');
    }
}

@Component({
    selector : 'parent',
    template : `
        <child (notifyParent)="getNotification($event)"></child>
    `
})
class Parent {
    getNotification(evt) {
        // Do something with the notification (evt) sent by the child!
    }
}

¿Cómo no usarlo?

class MyService {
    @Output() myServiceEvent : EventEmitter<any> = new EventEmitter();
}

Detente ahí ... ya estás equivocado ...

Esperemos que estos dos ejemplos simples aclaren el uso adecuado de EventEmitter.

Sí, adelante y úsalo.

EventEmitteres un tipo público y documentado en la API final de Angular Core. Si se basa o no Observablees irrelevante; si está documentado emitysubscribe métodos se ajustan a lo que necesita, continúe y úselo.

Como también se indica en los documentos:

Utiliza Rx.Observable pero proporciona un adaptador para que funcione como se especifica aquí: https://github.com/jhusain/observable-spec

Una vez que una implementación de referencia de la especificación esté disponible, cámbiela.

Entonces querían un Observableobjeto similar que se comportara de cierta manera, lo implementaron y lo hicieron público. Si se tratara simplemente de una abstracción angular interna que no debería usarse, no lo hubieran hecho público.

Hay muchas ocasiones en que es útil tener un emisor que envíe eventos de un tipo específico. Si ese es su caso de uso, hágalo. Si / cuando una implementación de referencia de la especificación a la que enlazan está disponible, debería ser un reemplazo directo, al igual que con cualquier otro polyfill.

Solo asegúrese de que el generador que pase a la subscribe()función siga las especificaciones vinculadas. Se garantiza que el objeto devuelto tiene un unsubscribemétodo que debería llamarse para liberar cualquier referencia al generador (actualmente es un objeto RxJsSubscription pero de hecho es un detalle de implementación del que no se debe depender).

export class MyServiceEvent {
    message: string;
    eventId: number;
}

export class MyService {
    public onChange: EventEmitter<MyServiceEvent> = new EventEmitter<MyServiceEvent>();

    public doSomething(message: string) {
        // do something, then...
        this.onChange.emit({message: message, eventId: 42});
    }
}

export class MyConsumer {
    private _serviceSubscription;

    constructor(private service: MyService) {
        this._serviceSubscription = this.service.onChange.subscribe({
            next: (event: MyServiceEvent) => {
                console.log(`Received message #${event.eventId}: ${event.message}`);
            }
        })
    }

    public consume() {
        // do some stuff, then later...

        this.cleanup();
    }

    private cleanup() {
        this._serviceSubscription.unsubscribe();
    }
}

Todas las predicciones pesimistas y pesimistas fuertemente redactadas parecen provenir de un solo comentario de Stack Overflow de un solo desarrollador en una versión preliminar de Angular 2.

Cuando desee tener interacción entre componentes, debe saber qué son @Input, @Output, EventEmitter y Subjects.

Si la relación entre los componentes es padre-hijo o viceversa, usamos @input & @output con el emisor de eventos.

@output emite un evento y debe emitir utilizando el emisor de eventos.

Si no se trata de una relación padre-hijo ... entonces debe usar temas o mediante un servicio común.

No hay: nono y no: sí, sí. La verdad está en el medio Y no hay razones para tener miedo debido a la próxima versión de Angular.

Desde un punto de vista lógico, si tiene un componente y desea informar a otros componentes de que algo sucede, se debe activar un evento y esto se puede hacer de la forma que usted (desarrollador) piense que debería hacerse. No veo la razón por la que no lo uso y no veo la razón por la que lo uso a toda costa. También el nombre de EventEmitter me sugiere que suceda un evento. Usualmente lo uso para eventos importantes que suceden en el Componente. Creo el servicio pero creo el archivo de servicio dentro de la carpeta de componentes. Por lo tanto, mi archivo de Servicio se convierte en una especie de Administrador de eventos o una Interfaz de eventos, de modo que puedo averiguar a simple vista a qué evento puedo suscribirme en el componente actual.

Lo sé ... Tal vez soy un desarrollador un poco anticuado. Pero esto no es parte del patrón de desarrollo Event Driven, es parte de las decisiones de arquitectura de software de su proyecto en particular.

Algunos otros chicos pueden pensar que usar Observables directamente es genial. En ese caso, continúe con Observables directamente. No eres un asesino en serie haciendo esto. A menos que sea un desarrollador psicópata, hasta ahora el programa funciona, hágalo.