Saya telah membaca pertanyaan seperti Layanan Access EventEmitter di dalam CustomHttp di mana pengguna menggunakan EventEmitter dalam layanannya, tetapi dia disarankan dalam komentar ini untuk tidak menggunakannya dan untuk menggunakannya sebagai pengamat langsung dalam layanannya.

Saya juga membaca pertanyaan ini di mana solusinya menyarankan untuk meneruskan EventEmitter ke anak dan berlangganan.

Pertanyaan saya kemudian adalah: Haruskah saya, atau saya tidak boleh berlangganan secara manual ke EventEmitter? Bagaimana saya harus menggunakannya?

TL; DR :

Tidak, jangan berlangganan secara manual kepada mereka, jangan menggunakannya dalam layanan. Gunakan mereka seperti yang ditunjukkan dalam dokumentasi hanya untuk memancarkan peristiwa dalam komponen. Jangan mengalahkan abstraksi sudut.

Menjawab:

Tidak, Anda tidak harus berlangganan secara manual.

EventEmitter adalah abstraksi angular2 dan satu-satunya tujuannya adalah untuk memancarkan peristiwa dalam komponen. Mengutip komentar dari Rob Wormald

[...] EventEmitter benar-benar abstraksi Angular, dan harus digunakan cukup banyak hanya untuk memancarkan Acara kustom dalam komponen. Kalau tidak, cukup gunakan Rx seolah-olah itu perpustakaan lain.

Ini dinyatakan sangat jelas dalam dokumentasi EventEmitter.

Gunakan dengan arahan dan komponen untuk memancarkan Acara kustom.

Apa yang salah dengan menggunakannya?

Angular2 tidak akan pernah menjamin kami bahwa EventEmitter akan terus menjadi Observable. Jadi itu berarti refactoring kode kita jika ada perubahan. Satu-satunya API yang harus kita akses adalah emit()metodenya. Kita tidak boleh berlangganan secara manual ke EventEmitter.

Semua yang dinyatakan di atas lebih jelas dalam komentar Ward Bell ini (disarankan untuk membaca artikel, dan jawaban untuk komentar itu). Mengutip untuk referensi

JANGAN mengandalkan EventEmitter yang terus menjadi Observable!

JANGAN mengandalkan operator yang bisa diamati itu di masa depan!

Ini akan segera ditinggalkan dan mungkin dihapus sebelum rilis.

Gunakan EventEmitter hanya untuk pengikatan acara antara komponen anak dan orang tua. Jangan berlangganan untuk itu. Jangan panggil metode tersebut. Hanya panggilaneve.emit()

Komentarnya sudah sesuai dengan komentar Rob sejak dulu.

Jadi, bagaimana cara menggunakannya dengan benar?

Cukup gunakan untuk memancarkan acara dari komponen Anda. Lihatlah contoh berikut.

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

Bagaimana tidak menggunakannya?

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

Berhenti di sana ... Anda sudah salah ...

Semoga dua contoh sederhana ini akan menjelaskan penggunaan yang tepat dari EventEmitter.

Ya, silakan dan gunakan.

EventEmitteradalah tipe publik dan terdokumentasi dalam API Inti Sudut akhir. Apakah didasarkan atau tidak itu tidak Observablerelevan; jika didokumentasikan emitdan subscribemetode yang sesuai dengan apa yang Anda butuhkan, maka maju dan gunakan.

Seperti yang dinyatakan dalam dokumen:

Menggunakan Rx.Observable tetapi menyediakan adaptor untuk membuatnya berfungsi seperti yang ditentukan di sini: https://github.com/jhusain/observable-spec

Setelah implementasi referensi dari spesifikasi tersedia, beralihlah ke sana.

Jadi mereka menginginkan Observableobjek serupa yang berperilaku dengan cara tertentu, mereka mengimplementasikannya, dan mempublikasikannya. Jika itu hanya abstraksi sudut internal yang tidak boleh digunakan, mereka tidak akan dipublikasikan.

Ada banyak waktu ketika berguna untuk memiliki emitor yang mengirimkan peristiwa dari tipe tertentu. Jika itu kasus penggunaan Anda, lakukan. Jika / ketika implementasi referensi dari spec yang mereka tautkan tersedia, itu harus menjadi pengganti drop-in, seperti halnya dengan polyfill lainnya.

Pastikan saja generator yang Anda operasikan ke subscribe()fungsi mengikuti spesifikasi yang ditautkan. Objek yang dikembalikan dijamin memiliki unsubscribemetode yang harus dipanggil untuk membebaskan referensi ke generator (ini saat ini merupakan objek RxJsSubscription tetapi itu memang detail implementasi yang tidak boleh bergantung pada).

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

Semua prediksi azab dan kemuraman yang sangat kuat tampaknya berasal dari komentar Stack Overflow tunggal dari pengembang tunggal pada versi pra-rilis Angular 2.

Saat Anda ingin memiliki interaksi lintas komponen, maka Anda perlu tahu apa itu @Input, @Output, EventEmitter, dan Subjek.

Jika hubungan antara komponen adalah orangtua-anak atau sebaliknya kita menggunakan @input & @output dengan event emitor ..

@output memancarkan suatu acara dan Anda harus memancarkannya menggunakan emitor acara.

Jika itu bukan hubungan anak orang tua .. maka Anda harus menggunakan subjek atau melalui layanan umum.

Tidak ada: nono dan tidak: yesyes. Kebenarannya ada di tengah dan tidak ada alasan untuk takut karena versi Angular berikutnya.

Dari sudut pandang logis, jika Anda memiliki Komponen dan Anda ingin memberi tahu komponen lain bahwa sesuatu terjadi, suatu peristiwa harus dipecat dan ini dapat dilakukan dengan cara apa pun yang menurut Anda (pengembang) harus dilakukan. Saya tidak melihat alasan mengapa tidak menggunakannya dan saya tidak melihat alasan mengapa menggunakannya dengan cara apa pun. Juga nama EventEmitter menunjukkan kepada saya suatu peristiwa yang terjadi. Saya biasanya menggunakannya untuk acara penting yang terjadi di Komponen. Saya membuat Layanan tetapi membuat file Layanan di dalam Folder Komponen. Jadi file Layanan saya menjadi semacam Manajer Acara atau Antarmuka Acara, jadi saya dapat mengetahui secara sekilas peristiwa mana yang dapat saya ikuti pada komponen saat ini.

Saya tahu .. Mungkin saya sedikit pengembang kuno. Tetapi ini bukan bagian dari pola pengembangan Event Driven, ini adalah bagian dari keputusan arsitektur perangkat lunak proyek khusus Anda.

Beberapa orang lain mungkin berpikir bahwa menggunakan Observables secara langsung itu keren. Dalam hal ini langsung saja dengan Observables. Anda bukan pembunuh berantai yang melakukan ini. Kecuali jika Anda seorang pengembang psikopat, Sejauh ini Program bekerja, lakukanlah.