Angular Component Interaction: input, output, viewChild (2026)

Quick answer: Angular component interaction runs in two directions. Data flows down through input(), and events flow up through output(). To reach a child that is already rendered, use a viewChild query. For content passed into a component from its host, use contentChild. Inputs down, outputs up is the rule that keeps a component tree predictable.The sections below cover Angular component interaction in both directions: inputs down, outputs up, then viewChild and contentChild for the cases where the tree is not enough — and when Angular component interaction should move into a shared service instead. That service usually exposes a stream, and the RxJS operators in Angular guide covers the patterns that keep it predictable.

Passing data down with input

An input is a value the parent sets on the child. The modern signal form uses the input() function, which makes the value reactive and read-only inside the child.

import { Component, input } from '@angular/core';

@Component({
  selector: 'app-stars',
  template: `<span>{{ rating() }} / 5</span>`,
})
export class StarsComponent {
  rating = input.required<number>();
  label = input('Rating');
}

The parent binds it the same way it binds any property: <app-stars [rating]="product.stars" />. Note the single brackets — this is the property binding from the previous article. input.required makes the value mandatory, so forgetting to pass it is a compile error.

Sending events up: Angular component interaction with output

When something happens inside a child and the parent needs to know, the child emits an output. The parent then handles it like a DOM event.

import { Component, output } from '@angular/core';

@Component({
  selector: 'app-rating-input',
  template: `<button (click)="choose(4)">4 stars</button>`,
})
export class RatingInputComponent {
  rated = output<number>();
  protected choose(value: number) {
    this.rated.emit(value);
  }
}

The parent listens with parentheses, the same syntax as a click handler:

<app-rating-input (rated)="saveRating($event)" />

$event carries whatever the child emitted — here, the number of stars. Inputs carrying data down and outputs carrying events up is the whole contract between a parent and child.

Reading a child with viewChild

Sometimes the parent needs to call a method on the child directly, or read a value from it. A view query gives you a reference to the child instance.

import { Component, viewChild, AfterViewInit } from '@angular/core';
import { ChartComponent } from './chart.component';

@Component({
  selector: 'app-report',
  imports: [ChartComponent],
  template: `<app-chart />`,
})
export class ReportComponent implements AfterViewInit {
  chart = viewChild.required(ChartComponent);

  ngAfterViewInit() {
    this.chart().render();
  }
}

The child exists only after the view renders, so the first safe moment to use the reference is ngAfterViewInit. Calling into a child this way is a useful escape hatch, but prefer inputs and outputs where you can — they are easier to trace.

Receiving markup with contentChild

Content projection is for wrapping. A card component wants to accept whatever the parent puts between its tags, and sometimes inspect that content if it is another component.

@Component({
  selector: 'app-panel',
  template: `
    <section class="panel">
      <ng-content />
    </section>
  `,
})
export class PanelComponent {}

The parent then writes <app-panel><p>Anything here.</p></app-panel>, and <ng-content /> marks where that markup appears. Use contentChild when the wrapped content is a specific component and the panel needs to read from it.

Angular component interaction: choosing the right mechanism

If two distant components must share state, do not thread inputs through five layers. Put the state in a service and inject it into both — see services and dependency injection, or the shared-state patterns in signals and state management.

Prefer learning component patterns on a real project? Ampersand Academy teaches Angular one-to-one, from components to deployed apps.

Common angular component interaction pitfalls and how to avoid them

Even when the mechanisms are clear, angular component interaction breaks down in predictable ways. Knowing the failure patterns saves hours of debugging. The sections below walk through the most common mistakes: mutating inputs, emitting too often, querying too early, and letting signal reads happen outside a reactive context.

Mutating signal inputs breaks unidirectional flow

Signal inputs are read-only by design. Attempting to write to an input() value inside the child throws a runtime error. The child owns nothing the parent passes down — it can only read and react. Treating a signal input as a writable variable is the single most common mistake developers make when migrating from the decorator-based @Input() API to the modern function form.

The correct pattern is to derive a new local signal from the input using computed(). That keeps the parent’s value untouched while giving the child a value it controls.

import { Component, input, computed } from '@angular/core';

@Component({
  selector: 'app-price',
  template: `{{ discounted() }}`,
})
export class PriceComponent {
  amount = input.required<number>();
  // Derive locally — never write back to amount()
  discounted = computed(() => this.amount() * 0.9);
}

import { Component, input, computed } from '@angular/core';@Component({ selector: 'app-price', template: `{{ discounted() }}`, }) export class PriceComponent { amount = input.required<number>(); // Derive locally — never write back to amount() discounted = computed(() => this.amount() * 0.9); }

The parent remains the single source of truth for amount. The child computes a view-only derivative. Angular component interaction stays predictable because data still flows in one direction only — the child never pushes a changed value back through the same channel it arrived on.

Emitting on every keystroke floods the parent

An output() emit is synchronous. If a child emits inside an input event handler without debouncing, the parent’s handler fires on every character. For expensive operations — API calls, large state recalculations — this destroys performance. Angular component interaction through outputs is cheap, but the parent’s response to those outputs may not be.

Debounce inside the child before emitting, or accept a debounce delay as an input. Keep the debounce logic inside the child so the parent contract stays simple: it still just listens for (searched) and receives a settled string.

import { Component, output, input } from '@angular/core';

@Component({
  selector: 'app-search-box',
  template: `<input (input)="onInput($event)" />`,
})
export class SearchBoxComponent {
  debounceMs = input(300);
  searched = output<string>();

  private timer: ReturnType<typeof setTimeout> | null = null;

  protected onInput(event: Event) {
    const value = (event.target as HTMLInputElement).value;
    if (this.timer) clearTimeout(this.timer);
    this.timer = setTimeout(
      () => this.searched.emit(value),
      this.debounceMs()
    );
  }
}

import { Component, output, input } from '@angular/core';@Component({ selector: 'app-search-box', template: `<input (input)="onInput($event)" />`, }) export class SearchBoxComponent { debounceMs = input(300); searched = output<string>();private timer: ReturnType<typeof setTimeout> | null = null;protected onInput(event: Event) { const value = (event.target as HTMLInputElement).value; if (this.timer) clearTimeout(this.timer); this.timer = setTimeout( () => this.searched.emit(value), this.debounceMs() ); } }

Accepting debounceMs as an input keeps the component reusable. A search page might want 300 ms; an autocomplete might want 150 ms. The parent controls the delay without touching the debounce logic. This is angular component interaction working at its cleanest: behaviour configured from outside, implementation hidden inside.

viewChild timing, signal queries, and template references

The biggest source of confusion with viewChild is timing. Angular builds the view tree in a specific order and the query result is only populated after that build completes. Getting this wrong produces undefined reads that appear randomly and are hard to reproduce.

Querying too early produces undefined

Reading a viewChild result inside the constructor or ngOnInit returns undefined because the template has not rendered yet. The safe lifecycle hook is ngAfterViewInit. With the signal form of viewChild, you can also read the result inside a computed() or an effect(), and Angular will re-evaluate when the query resolves — which also avoids the timing problem for most reactive patterns.

Using viewChild.required() makes the intention explicit: if the child is somehow absent, Angular throws rather than silently returning undefined. Prefer required unless the child is inside an @if block and genuinely may not exist.

Template reference variables as an alternative

When the parent only needs to pass a reference to a native element — not call methods on a child component — a template reference variable combined with viewChild is cleaner than querying the component class. Pass a string token to the query matching the variable name in the template.

import { Component, viewChild, ElementRef, AfterViewInit } from '@angular/core';

@Component({
  selector: 'app-focus-demo',
  template: `<input #searchInput type="text" />`,
})
export class FocusDemoComponent implements AfterViewInit {
  searchInput = viewChild.required<ElementRef>('searchInput');

  ngAfterViewInit() {
    this.searchInput().nativeElement.focus();
  }
}

import { Component, viewChild, ElementRef, AfterViewInit } from '@angular/core';@Component({ selector: 'app-focus-demo', template: `<input #searchInput type="text" />`, }) export class FocusDemoComponent implements AfterViewInit { searchInput = viewChild.required<ElementRef>('searchInput');ngAfterViewInit() { this.searchInput().nativeElement.focus(); } }

The string 'searchInput' matches the #searchInput variable in the template. Angular component interaction with the DOM works the same way as interaction with a child component — query, wait for view init, then act. Avoid caching nativeElement references in component properties; always read through the signal to catch cases where the element is conditionally removed and re-added.

Two-way angular component interaction with model()

Angular 17.2 introduced model(), a signal that combines an input and a matching output into a single declaration. It covers the common pattern where a child receives a value and can also change it — think a toggle, a slider, or a controlled text field. Without model(), this requires an input() and a separate output() whose name is the input name plus Change, which is verbose and error-prone.

Angular component interaction through model() uses the same banana-in-a-box syntax as the older ngModel: [(value)]="localVariable". The parent’s variable updates automatically when the child writes to the model signal. The child writes to it just like a writable signal — no emit() call needed.

import { Component, model } from '@angular/core';

@Component({
  selector: 'app-toggle',
  template: `
    <button (click)="toggle()">{{ on() ? 'On' : 'Off' }}</button>
  `,
})
export class ToggleComponent {
  on = model(false);

  protected toggle() {
    this.on.set(!this.on());
  }
}

// Parent template:
// <app-toggle [(on)]="featureEnabled" />

import { Component, model } from '@angular/core';@Component({ selector: 'app-toggle', template: ` <button (click)="toggle()">{{ on() ? 'On' : 'Off' }}</button> `, }) export class ToggleComponent { on = model(false);protected toggle() { this.on.set(!this.on()); } }// Parent template: // <app-toggle [(on)]="featureEnabled" />

The parent binds [(on)]="featureEnabled". When the child calls this.on.set(true), Angular propagates the new value back to featureEnabled in the parent. The child can also read the value as a normal signal — this.on() — making it reactive in templates and computed properties without extra wiring.

Use model() only for genuinely two-way state. A rating selector that both shows a current rating and lets the user pick a new one is a good fit. A read-only display component is not — use a plain input() there. Overusing model() blurs the data-flow direction that makes angular component interaction easy to trace.

Multi-level angular component interaction and the service boundary

Inputs and outputs work well one level deep. Two levels is manageable. Three or more levels of prop-drilling — passing the same value through grandparent, parent, and child just so the grandchild can read it — is a sign the data belongs in a service, not in the component tree.

The rule is practical, not dogmatic. If the intermediate component genuinely uses the value itself, passing it as an input is correct. If the intermediate component only forwards it without using it, that is prop-drilling and a service solves it better. Angular component interaction through a shared signal service keeps each component’s inputs and outputs minimal and focused on what that component actually does.

A lightweight shared service for this case needs very little code. Declare a signal at the service level, inject the service into each component that needs the value, and read or write directly. No inputs, no outputs, no threading through layers.

Signals in services are also the right answer when two sibling components — neither parent nor child — need to synchronise state. There is no direct angular component interaction path between siblings. The shared service acts as the meeting point. Both siblings inject it, one writes, the other reads reactively.

Step-by-step workflow for designing angular component interaction

Before writing any binding code, deciding which mechanism to use prevents refactoring later. This workflow gives a repeatable decision path for any new component relationship.

1. Draw the relationship. Is one component the direct parent of the other in the template? If yes, inputs and outputs are the first option. If they are siblings or far apart in the tree, skip to step five.
2. Determine direction. Does the parent configure the child? Use input(). Does the child report back to the parent? Use output(). Is the value genuinely two-way? Use model().
3. Check for content projection. Does the parent wrap arbitrary markup inside the child’s tags? Add <ng-content />. Does the parent wrap a specific known component? Add contentChild to inspect it.
4. Consider imperative access. Does the parent need to call a method on the child — for example, triggering animation or resetting a form? Use viewChild. Keep these calls rare; prefer reactive inputs where possible.
5. Check depth and siblings. Are more than two intermediate components involved? Are the components siblings? Move shared state into a signal service. Angular component interaction through a service is not a workaround — it is the correct tool at that scale.

Following these steps in order means the simplest mechanism always wins. Most angular component interaction in a well-designed app is just inputs and outputs. Queries and services appear only where they genuinely reduce complexity, not as a default.

Testing angular component interaction in isolation

Each mechanism has a natural testing approach. Knowing it avoids over-engineering tests and keeps them fast and readable.

For input(), set values through Angular’s TestBed fixture and call fixture.detectChanges() to propagate them. With signal inputs, use fixture.componentRef.setInput('rating', 4) — this is the recommended way to trigger input changes in tests without constructing a real parent component.

For output(), subscribe to the output on the component instance and collect emitted values in an array. Then trigger the action that causes the emit, and assert the array. Angular component interaction tests for outputs stay synchronous unless the child introduces a timer, in which case use fakeAsync and tick().

For viewChild, the query resolves after fixture.detectChanges() in a test. The lifecycle hook pattern works the same way — after change detection, the signal is populated. Tests that call into the child through a viewChild reference should spy on the child component method rather than asserting on side effects, keeping angular component interaction tests focused and isolated.

For model(), set the initial value through setInput, trigger the child action, and assert that the model signal now holds the expected value. Because model() is a writable signal, reading it in the test is direct — no subscription needed.

Well-tested angular component interaction means each component is tested alone, with its inputs set explicitly and its outputs observed directly. Integration tests that mount a parent and child together are valuable for catching wiring errors, but unit tests give faster feedback on the logic inside each boundary. Keep both, and keep them short.

Frequently asked questions