Input and Output Decorators

Analogy categoryAnalogies

@Input() and @Output() are the classic, decorator-based mechanism Angular uses for parent-to-child and child-to-parent communication between components. @Input() marks a class property as bindable from a parent template using square-bracket property binding syntax, e.g. <app-card [title]="post.title">, allowing data to flow down the component tree. @Output() marks a property — conventionally an EventEmitter — as a source of custom events that a parent can listen to using parenthesis event binding syntax, e.g. <app-card (favorited)="onFavorite($event)">, allowing data and notifications to flow back up. Together they form the backbone of Angular's unidirectional-data-flow-with-events communication model, long before signal-based inputs existed.

🏏

Cricket analogy: @Input()/@Output() are like a captain relaying field placements down to fielders (@Input passing data to a child) while fielders shout back appeals up to the captain (@Output emitting events), a two-way but distinctly directional flow.

Declaring and Binding @Input Properties

A property decorated with @Input() becomes settable from outside the component. By default the binding name matches the property name, but you can alias it, e.g. @Input('cardTitle') title!: string, so the template uses [cardTitle] while the class uses this.title. Since Angular 16, you can also mark an input as required with @Input({ required: true }), which causes a compile-time error if a parent forgets to bind it — closing a long-standing gap where required inputs could only be enforced by convention or the definite-assignment assertion (!). Angular 16 also introduced input transform functions via @Input({ transform: fn }), letting you coerce incoming values, such as converting string attribute values to booleans or numbers, right at the binding boundary.

🏏

Cricket analogy: Aliasing @Input('cardTitle') is like a player being registered on the scoreboard as 'Kohli' while the team roster internally calls him by his full legal name; required inputs are like a toss rule that voids the match if a captain forgets to call heads or tails.

typescript

@Component({
  selector: 'app-card',
  standalone: true,
  template: `
    <div class="card">
      <h3>{{ title }}</h3>
      <button (click)="favorited.emit(id)">♥ Favorite</button>
    </div>
  `
})
export class CardComponent {
  @Input({ required: true }) title!: string;
  @Input() id: number = 0;
  @Output() favorited = new EventEmitter<number>();
}

Emitting Events with @Output

An @Output() property is typically typed as EventEmitter<T>, a thin wrapper around RxJS's Subject that adds an .emit(value) convenience method. When the parent template binds (favorited)="onFavorite($event)", the $event variable receives whatever value was passed to .emit(). It's a common convention — though not enforced by the compiler — to name output properties as past-tense or descriptive event names (favorited, closed, valueChanged) rather than prefixing them with 'on', since the 'on' prefix is reserved by convention for the handler method in the parent, avoiding naming collisions and confusion like (onFavorited)="onFavorited()".

🏏

Cricket analogy: EventEmitter wrapping a Subject is like a stump microphone that simply relays whatever sound occurs at the crease (.emit(value)) to the broadcast booth, and naming it 'wicketFallen' instead of 'onWicket' avoids confusing it with the commentator's own reaction call.

typescript

@Component({
  selector: 'app-parent',
  standalone: true,
  imports: [CardComponent],
  template: `
    <app-card [title]="'Angular Basics'" [id]="42"
              (favorited)="handleFavorite($event)">
    </app-card>
  `
})
export class ParentComponent {
  handleFavorite(cardId: number): void {
    console.log('Favorited card', cardId);
  }
}

@Input()/@Output() are conceptually similar to React's props and callback props, or Vue's props/emit pattern — data flows down via bound properties, and events/callbacks flow up. The key Angular-specific nuance is that @Output() properties are full RxJS-flavored EventEmitters, so in principle you could .subscribe() to them programmatically (e.g. via ViewChild) in addition to template binding, though template binding is the idiomatic approach.

Calling .complete() on an @Output() EventEmitter, or forgetting that EventEmitter extends Subject (not Observable in the read-only sense), can lead to subtle bugs — most developers should only ever call .emit(), never .next(), .complete(), or .error() directly on an output, since Angular's binding machinery expects an event emitter, not a general-purpose stream to be manually managed.

Since Angular 17.1, @Input() and @Output() have signal-based counterparts — input() and output() functions — which are now the recommended default for new code because they integrate more naturally with signals and OnPush change detection. However, @Input()/@Output() remain fully supported, are still extremely common in existing codebases, and are essential to understand when maintaining or reading pre-signals Angular applications.

🏏

Cricket analogy: Signal-based input()/output() replacing decorators is like a franchise switching from the old paper scorebook system to an integrated digital scoring system that syncs automatically, while veteran scorers who learned the paper method are still fully able to work any match.

@Input() exposes a class property for parent-to-child binding via square brackets: [propName]="expr".
@Output() exposes an EventEmitter for child-to-parent notification via parentheses: (eventName)="handler($event)".
@Input({ required: true }) enforces at compile time that a parent must bind the input.
@Input({ transform: fn }) lets you coerce/normalize incoming values at the binding boundary (e.g. string to boolean).
Output property names conventionally avoid an 'on' prefix to prevent confusion with the parent's handler method name.
EventEmitter should generally only be used with .emit() in components; input()/output() signal functions are the modern recommended alternative.