Я читав такі питання, як Access EventEmitter Service всередині CustomHttp, де користувач використовує EventEmitter у своїй службі, але він запропонований у цьому коментарі не використовувати його, а використовувати замість Observables безпосередньо у своїх послугах.

Я також прочитав це питання, де рішення пропонує передати EventEmitter дитині та підписатися на нього.

Моє питання тоді: чи повинен я чи не повинен підписуватись вручну на EventEmitter? Як я повинен його використовувати?

TL; DR :

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

Відповідь:

Ні, ви не повинні підписатися на нього вручну.

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

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

Це сказано дійсно ясно в документації EventEmitter.

Використовуйте директивами та компонентами для передачі користувацьких подій.

Що не так у використанні?

Angular2 ніколи не гарантує нам, що EventEmitter продовжить бути спостережуваним. Отже, це означає рефакторинг нашого коду, якщо він зміниться. Єдиний API, до якого ми маємо отримати доступ, це йогоemit() метод. Ми ніколи не повинні підписуватись на EventEmitter вручну.

Все сказане вище зрозуміло в коментарі Уорда Белла (рекомендується прочитати статтю та відповідь на цей коментар). Цитуючи довідку

НЕ розраховуйте на те, що EventEmitter продовжує бути спостерігачем!

НЕ розраховуйте на те, що ті оператори, які спостерігаються, будуть там у майбутньому!

Вони будуть застарілі найближчим часом і, ймовірно, будуть видалені перед випуском.

Використовуйте 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є загальнодоступним, задокументованим типом у заключному API Angular Core. Незалежно від того, ґрунтується чи ні, не 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.

Коли ви хочете мати взаємодію між компонентами, вам потрібно знати, що таке @ вхід, @ вихід, EventEmitter та суб'єкти.

Якщо співвідношення між компонентами є батьківським дочірнім або навпаки, ми використовуємо @input & @output з емітером подій.

@output посилає подію, і її потрібно випромінювати, використовуючи емітер події.

Якщо це не стосунки з батьками-дітьми .. тоді вам доведеться користуватися предметами або через загальну службу.

Немає: nono і no: yesyes. Правда в середині І немає причин лякатися через чергову версію Angular.

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

Я знаю .. Можливо, я трохи старомодний розробник. Але це не є частиною моделі розвитку, керованої подіями, це частина рішення архітектури програмного забезпечення вашого конкретного проекту.

Деякі інші хлопці можуть подумати, що використовувати Observables безпосередньо - це класно. У такому випадку продовжуйте роботу безпосередньо з спостерігачами. Ви не серійний вбивця, який робить це. Якщо ви не розробник психопатів, поки програма працює, робіть це.