Angular @Output(): Child Components Reporting Up

An @Output() lets a child component tell its parent something happened, using an EventEmitter. It’s the standard way to handle events like button clicks that the parent needs to act on. The footgun is forgetting to actually .emit() the event.
Why it exists
Angular's component architecture promotes encapsulation, where components are self-contained units. By default, data flows down from parent to child via @Input(). This creates a predictable data flow but raises a question: how does a child communicate back up to its parent? @Output() exists to solve this, providing a clean, one-way channel for events to flow upwards without breaking encapsulation.
The mental model
Think of @Output() as installing a doorbell on a child component's "house". The child component itself decides when to ring that bell by calling the .emit() method. The parent component, which placed the child component, listens for the ring. The parent decides what to do when it hears the bell, but the child doesn't know or care. It just announces that something happened.
How it works
In the child component, you declare a property and decorate it with @Output(). This property must be a new instance of EventEmitter. For example: @Output() somethingHappened = new EventEmitter<string>();. When an event occurs in the child, like a button click, you call this.somethingHappened.emit('some data'). In the parent component's template, you bind to this event using parentheses: <app-child (somethingHappened)="parentMethod(event)"></app-child>. The event variable contains the data that was emitted.
When to use it
Use @Output() for any communication from a child to its immediate parent. This is the canonical pattern for handling user interactions within a child component that the parent needs to be aware of. Examples include a "delete" button in a list item, a "submit" event from a custom form control, or a "close" action on a modal dialog.
When not to use it
Avoid using @Output() for communicating between distant or unrelated components. Chaining events up multiple levels of the component tree is cumbersome and creates tight coupling. For cross-component communication, a shared service with an RxJS Subject or a state management library is a better solution. Also, never use @Output() to pass data down to a child; that is the specific job of @Input().
One canonical example
A child component, TodoItemComponent, displays a single todo and has a "complete" button. It defines @Output() complete = new EventEmitter<number>();. When its button is clicked, it calls this.complete.emit(this.todo.id). The parent TodoListComponent uses it in a loop: <app-todo-item *ngFor="let todo of todos" [todo]="todo" (complete)="markAsComplete($event)"></app-todo-item>. The parent's markAsComplete method then receives the ID of the completed todo.
Interview question
How does an Angular child component typically notify its immediate parent about an internal event, such as a button click?
- a.By directly invoking a method defined on the parent component instance.
- b.By updating a shared service's observable that the parent component is subscribed to.
- c.By receiving a callback function from the parent via @Input() and executing it.
- d.By using an @Output() property initialized with EventEmitter and calling its emit() method.Correct
Why? this is the answer
The @Output() decorator, paired with an EventEmitter and its emit() method, is the canonical Angular pattern for a child component to send events and data upwards to its immediate parent. Option B describes a pattern for communication between distant components, not the immediate parent. Options B and D are not the standard or recommended Angular approaches for this specific child-to-parent event notification.
Just read this? Test yourself on what you have been reading.
Read the original → angular.dev
- #angular
- #component-communication
- #typescript
- #frontend
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on angular — each one lists the topics its interview covers.
See open roles