Dies ist eine Design-Perspektive.
Im Allgemeinen, was ich herausgefunden habe, ist, wenn die Anwendungsgröße mittel bis sehr groß ist, gehen Sie dann für Shared Services entweder Behaviour Subject oder Replay Subject, um Nachricht an andere Komponenten zu übertragen.
Und noch besser Design ist für ngrx i: e mit Redux in Angular gehen. Der einzige Nachteil ist der zusätzliche Code, den Sie für Ihre Aktionen und Reduzierungen schreiben müssen, aber das Plus ist die ganze Logik ist von den Komponenten getrennt, die in redux Welt als dumme Komponenten bekannt sind. Sobald es fertig ist, wird es ein Lebensretter sein, der ngrx dev tools verwendet, um den Zustand zu jedem Zeitpunkt zu verfolgen, und es wird Ihnen leicht sein zu verfolgen, welches Ereignis oder welche Aktion ausgelöst wird, wann und wie Sie den Code debuggen und ergänzen.
Nur wenn Ihre App-Größe klein ist, werde ich vorschlagen, dass Sie mit Event-Emittern gehen, wie mit mehreren verschachtelten Komponenten, die Sie in einem Spaghetti-Code verschlingen. Sie können nicht alle Abfeuerungsereignisse verfolgen und dann schreiben Sie Ihren Code.
Mehr über die Verwendung von Ereignis-Emitter vs Shared Services LINK. Es gibt eine spezielle Frage nur dafür.
Mehr auf ngrx LINK. Dieser Link verwendet ngrx v2.
Ich habe auf einer kleinen App NGRX v.4 und das folgende ist das git-Repo für den gleichen git und der Arbeits arbeitete example