Я читал такие вопросы, как Access EventEmitter Service внутри CustomHttp, где пользователь использует EventEmitter в своем сервисе, но ему было предложено в этом комментарии не использовать его и использовать вместо него Observables непосредственно в своих сервисах.

Я также прочитал этот вопрос, где решение предлагает передать EventEmitter ребенку и подписаться на него.

Мой вопрос: я должен или не должен подписываться вручную на EventEmitter? Как я должен использовать это?

TL; DR :

Нет, не подписывайтесь на них вручную, не используйте их в сервисах. Используйте их, как показано в документации, только для генерации событий в компонентах. Не побеждайте угловую абстракцию.

Ответ:

Нет, вы не должны подписываться на него вручную.

EventEmitter является абстракцией angular2, и его единственная цель - генерировать события в компонентах. Цитирую комментарий от Роба Вормальда

[...] EventEmitter - это действительно угловая абстракция, и его следует использовать в основном только для создания пользовательских событий в компонентах. В противном случае просто используйте Rx, как если бы это была любая другая библиотека.

Это действительно ясно указано в документации к EventEmitter.

Используйте директивы и компоненты для создания пользовательских событий.

Что плохого в его использовании?

Angular2 никогда не гарантирует нам, что EventEmitter останется наблюдаемым. Так что это означает рефакторинг нашего кода, если он меняется. Единственный API, к которому мы должны получить доступ - это его emit()метод. Мы никогда не должны подписываться вручную на EventEmitter.

Все вышеизложенное более четко видно в комментарии этого Уорд Белла (рекомендуется прочитать статью и ответ на этот комментарий). Цитирование для справки

НЕ рассчитывайте на то, что EventEmitter останется наблюдаемым!

НЕ рассчитывайте на тех операторов Observable, которые будут там в будущем!

Они скоро будут устаревшими и, вероятно, будут удалены перед выпуском.

Используйте EventEmitter только для привязки событий между дочерним и родительским компонентом. Не подписывайтесь на это. Не вызывайте ни один из этих методов. Только звонокeve.emit()

Его комментарий совпадает с комментарием Роба давным-давно.

Итак, как правильно его использовать?

Просто используйте его для генерации событий из вашего компонента. Посмотрите на следующий пример.

@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!
    }
}

Как не использовать это?

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

Стоп тут ... ты уже не прав ...

Надеемся, что эти два простых примера прояснят правильное использование EventEmitter.

Да, идти вперед и использовать его.

EventEmitterявляется открытым, документированным типом в окончательном Angular Core API. Основано ли это на Observableтом, не имеет значения; если его документированы emitи subscribeметоды соответствуют тому, что вам нужно, тогда используйте его.

Как также указано в документах:

Использует Rx.Observable, но предоставляет адаптер для его работы, как указано здесь: https://github.com/jhusain/observable-spec

Как только эталонная реализация спецификации станет доступна, переключитесь на нее.

Таким образом, они хотели Observableподобный объект, который вел себя определенным образом, они реализовали его и сделали его публичным. Если бы это была просто внутренняя угловая абстракция, которую не следует использовать, они бы не сделали ее общедоступной.

Есть много случаев, когда полезно иметь эмиттер, который отправляет события определенного типа. Если это ваш вариант использования, пойти на это. Если / когда доступна эталонная реализация спецификации, на которую они ссылаются, она должна быть заменой, как и любой другой полифилл.

Просто убедитесь, что генератор, который вы передаете subscribe()функции, соответствует связанной спецификации. Возвращенный объект гарантированно должен иметь unsubscribeметод, который должен вызываться для освобождения любых ссылок на генератор (в настоящее время это объект RxJs,Subscription но это действительно деталь реализации, от которой не следует зависеть).

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();
    }
}

Все строго сформулированные предсказания о гибели и унынии, кажется, происходят из одного комментария о переполнении стека от одного разработчика в предварительной версии Angular 2.

Если вы хотите взаимодействовать между компонентами, вам нужно знать, что такое @Input, @Output, EventEmitter и Subjects.

Если отношения между компонентами являются родительскими и дочерними, или наоборот, мы используем @input & @output с генератором событий.

@output испускает событие, и вам нужно отправить его с помощью генератора событий.

Если это не отношения между родителями и детьми ... тогда вы должны использовать предметы или через общий сервис.

Нет: nono и нет: yesyes. Истина в середине И нет причин бояться из-за следующей версии Angular.

С логической точки зрения, если у вас есть компонент, и вы хотите сообщить другим компонентам о том, что что-то происходит, событие должно быть запущено, и это может быть сделано любым способом, который вы (разработчик) считаете нужным. Я не вижу причины, почему бы не использовать его, и я не вижу причины, чтобы использовать его любой ценой. Также имя EventEmitter предлагает мне событие, которое происходит. Я обычно использую его для важных событий, происходящих в Компоненте. Я создаю Службу, но создаю файл Службы внутри Папки компонентов. Таким образом, мой файл службы становится своего рода диспетчером событий или интерфейсом событий, поэтому я могу сразу определить, на какое событие я могу подписаться в текущем компоненте.

Я знаю .. Может быть, я немного старомодный разработчик. Но это не часть модели разработки, управляемой событиями, это часть решений по архитектуре программного обеспечения вашего конкретного проекта.

Некоторые другие ребята могут подумать, что использовать Observables напрямую - это круто. В этом случае перейдите непосредственно к Observables. Вы не серийный убийца, делающий это. Если вы не разработчик психопатов, пока программа работает, делайте это.