rxjs Observable or Subject instead EventEmitter

📚 Docs or angular.io bug report

Description

In the times of Angular v2, there was a semi-official statement not to use rxjs Observable or Subject directly instead of EventEmitter because the implementation of EventEmitter might change in the future.

I am wondering if this is still valid today, given that rxjs is a first-class citizen of Angular and any serious project based on Angular?

I found myself always wishing to use observable or piped observable directly in my reactive component instead of going out of my way to call EventEmitter.emit.

If the statement is still valid, could it perhaps be valuable to be documented?

[atscott]

Discussed with @jelbourn and we think this isn’t something that needs official documentation or guidance. There are myriad of ways to not do something and we shouldn’t attempt to document them. Our docs give guidance on the provided APIs, not a list of unsupported use-cases.

As far as the question of using something other than EventEmitter goes, as long as you follow the interface you’re more or less safe. It’s just outside the official guidance and will not have official support. That said, it’s highly unlikely to change and even if it did, you’d know at compile-time so it’s more or less safe, relatively speaking.

[arch-daemone]

It’s not so much the EventEmitter’s public API that’s in question here. The question is whether we’re strictly allowed to assign plain Observables to class members that are attached to @Output attributes, instead of EventEmitters. To add an explicit type annotation to my earlier snippet:

class Component {
  @Output() entityIdChange: Observable<number> = this.entityFacade.entityId$;
}

The place to put such a statement might be somewhere like the docs on communication between components, and might be an “alert” box of some sort that says something like, “We use EventEmitters in these examples because they provide the emit method, making it easy to emit a value from anywhere in the component’s code or template. But if the only values to be emitted are all coming from a single Observable, it may make more sense to simply assign that Observable directly to the @Output field. This is possible, and works as you would expect.” Maybe with a StackBlitz example showing that it does indeed work, including that it is unsubscribed on teardown.