In Angular, how does the OutputEmitterRef returned by output() differ from an EventEmitter used with @Output, and what should you check when migrating?

## Two emitter types Angular has two objects behind a component output: - **`OutputEmitterRef<T>`**, returned by the `output()` function. It is a small, purpose-built class in `@angular/core` with two methods: `emit(value)` and `subscribe(callback)`. - **`EventEmitter<T>`**, used with the `@Output()` decorator. It **extends the RxJS `Subject`** and adds an `emit()` method that calls `next()`. Both implement Angular's `OutputRef<T>` interface, which is why a parent's template binding works the same for either. ## Where they differ | | `OutputEmitterRef` (`output()`) | `EventEmitter` (`@Output()`) | |---|---|---| | Base type | Angular class, no RxJS | RxJS `Subject` | | Methods | `emit`, `subscribe` | `emit`, plus the full Observable/Subject API: `pipe`, `next`, `error`, `complete` | | `subscribe()` returns | `OutputRefSubscription` with `unsubscribe()` | an RxJS `Subscription` | | Delivery | always synchronous | synchronous, or async if built with `new EventEmitter(true)` | | A listener throws | the error goes to Angular's `ErrorHandler`; remaining listeners still run | RxJS `Subject` error semantics apply | | On component destroy | listeners dropped automatically | template listeners are cleaned up by Angular; manual subscriptions are yours | | `emit()` after destroy | ignored, with a dev warning (NG0953) | still calls `next()` on the subject | | `subscribe()` after destroy | throws NG0953 | allowed | | Template binding and `$event` | identical | identical | ## Why output() was introduced `EventEmitter` exposes much more than an output needs. Because it is a `Subject`, code could `pipe()` it, call `error()` or `complete()` on it, or subscribe in ways that outlive the component, and it ties every component with an output to RxJS. `OutputEmitterRef` keeps the contract minimal: 1. **Only emit and subscribe.** There is nothing to complete or error, so no consumer can end the stream. 2. **Lifecycle-aware.** It captures the component's `DestroyRef` when created. On destroy it marks itself destroyed and drops all listeners, so a subscriber cannot keep a destroyed component's emitter alive, and late emits are harmless no-ops. 3. **Error isolation.** Each listener runs in its own `try/catch`; an exception is reported to `ErrorHandler` and does not stop the other listeners. 4. **No RxJS requirement.** Components can have outputs without importing any RxJS type. ## Emitting from reactive code Both emitters run their listeners **untracked** with respect to signals: `emit()` clears the active reactive consumer before calling listeners. Emitting from inside an `effect()` therefore does not make the effect depend on whatever the listeners read. ## Converting between the two worlds When a component already has an Observable and wants to expose it as an output, or a consumer wants an output as an Observable, Angular provides dedicated interop functions in `@angular/core/rxjs-interop`. That is a separate subject; the point here is that `OutputEmitterRef` itself is **not** an Observable, so `this.rated.pipe(...)` does not compile. ## Migrating Parents do not change: `(rated)="save($event)"` works for both. In the child: ```ts import { Component, EventEmitter, Output, output } from '@angular/core'; @Component({ selector: 'app-rating-stars', template: '' }) export class RatingStars { // Before @Output() ratedLegacy = new EventEmitter<number>(); // After readonly rated = output<number>(); } ``` Things to check while migrating: - code that used the `EventEmitter` as a `Subject`, for example `this.rated.pipe(debounceTime(200))` or `subscribe` with an observer object, must be rewritten; - `new EventEmitter(true)` users relied on **asynchronous** delivery; `output()` is always synchronous, so timing-sensitive handlers may behave differently; - tests that subscribed to `componentInstance.rated` keep working, because `subscribe(callback)` exists on both, but the return type changes from `Subscription` to `OutputRefSubscription`. The Angular team recommends `output()` for new code and keeps `@Output` fully supported, so both appear side by side in real projects.