Angular 13 🅰️ Component Communication — @Input and @Output
Components don’t live in isolation. A parent renders a child, passes it data, and listens for events coming back. That’s component communication — the flow of information up and down the component tree. Angular’s two primitives for this are @Input (parent → child data) and @Output (child → parent events). Every UI you build in Angular is a tree of components passing data through these two decorators. Getting them right is the foundation of every component you’ll write.
Key point: Data flows down through @Input, events flow up through @Output. A child never reaches into its parent — it emits an event and lets the parent decide what to do. This one-way discipline keeps components reusable and testable. Break it by mutating inputs or reaching into parent state, and the component tree becomes a tangled mess.
The two directions
Component communication has exactly two directions:
┌──────────────────────────────────────┐
│ Parent │
│ │
│ [input] (output) │
│ │ ▲ │
│ ▼ │ │
│ ┌──────────────────────────────┐ │
│ │ Child │ │
│ └──────────────────────────────┘ │
│ │
└──────────────────────────────────────┘@Input— parent sends data down to child@Output— child sends events up to parent
Parent template:
<app-child
[data]="parentData"
(changed)="handleChange($event)">
</app-child>[data] is a property binding to the child’s @Input. (changed) is an event binding to the child’s @Output. The syntax is identical to binding DOM properties and events — because the same machinery handles both.
The rules:
- A child receives data via
@Input - A child emits events via
@Output - A child never reads or writes parent state directly
- A parent never calls methods on the child to get data (use outputs instead)
Why this discipline matters: Components are reusable only if their dependencies are explicit. If a child reached into its parent, it would only work inside that parent. By requiring inputs and outputs, Angular forces components to declare what they need and what they produce — making them portable.
Why one-way flow: Bidirectional data flow creates tangles. If a child can both read and write parent state, reasoning about where changes originate becomes impossible. Angular’s discipline — data down, events up — keeps the flow predictable. It’s the same idea as unidirectional data flow in Redux, applied at the component level.
@Input — receiving data
An @Input property is a doorway from the parent into the child.
import { Component, Input } from '@angular/core';
@Component({
selector: 'app-user-card',
standalone: true,
template: `
<div class="card">
<h3>{{ name }}</h3>
<p>{{ email }}</p>
</div>
`
})
export class UserCardComponent {
@Input() name = '';
@Input() email = '';
}The parent binds to those inputs:
<app-user-card [name]="user.name" [email]="user.email"></app-user-card>Angular assigns the bound values to the child’s properties. When the parent’s values change, Angular updates the child’s inputs.
Inputs are set after construction. The constructor runs before Angular assigns inputs. If you need to react to input values, use ngOnInit or ngOnChanges.
export class UserCardComponent implements OnInit {
@Input() userId!: number;
user?: User;
ngOnInit(): void {
// userId is now set
this.loadUser();
}
}The ! non-null assertion tells TypeScript that userId will be set before ngOnInit runs. Angular guarantees this.
Input types:
@Input() label = ''; // string with default
@Input() count = 0; // number
@Input() disabled = false; // boolean
@Input() items: string[] = []; // array
@Input() user!: User; // required, set by parent
@Input() config: Config | null = null; // nullableNaming conventions: The input name is the property name unless aliased. @Input() name is bound as [name]. @Input('firstName') name is bound as [firstName] but the property is name.
Required inputs: Angular 16+ supports @Input({ required: true }):
@Input({ required: true }) name!: string;The compiler errors if the parent doesn’t provide it. This catches mistakes at build time.
Why required inputs matter: Without them, a child could be used without providing a critical input, and the error would only appear at runtime.
required: truemoves the check to compile time. It’s a small win that compounds in larger codebases.
Aliasing inputs
An input’s template name can differ from its property name.
@Input('userName') name = '';Bound as:
<app-card [userName]="user.name"></app-card>Inside the class, it’s this.name. In templates, it’s [userName].
Why alias:
- Avoid collisions with HTML attributes
- Shorten names for readability
- Rename internally without breaking templates
- Match a public API established by convention
Common pattern:
@Input('ariaLabel') label = '';Now [ariaLabel] in templates maps to label in the class.
Aliases and required inputs:
@Input({ required: true, alias: 'userId' }) id!: number;[userId] is required; the property is id.
Why aliases are useful: They decouple the template API from the class implementation. You can rename the internal property without touching templates, or match an existing naming convention without renaming the class. It’s a small flexibility that pays off over time.
@Output — emitting events
An @Output property is an EventEmitter. The child calls .emit() to send a value up to the parent.
import { Component, EventEmitter, Output } from '@angular/core';
@Component({
selector: 'app-counter',
standalone: true,
template: `
<button (click)="increment()">+1</button>
<button (click)="reset()">Reset</button>
`
})
export class CounterComponent {
@Output() countChange = new EventEmitter<number>();
@Output() reset = new EventEmitter<void>();
private count = 0;
increment(): void {
this.count++;
this.countChange.emit(this.count);
}
resetCount(): void {
this.count = 0;
this.reset.emit();
}
}The parent listens:
<app-counter
(countChange)="onCount($event)"
(reset)="onReset()">
</app-counter>$event is the value passed to .emit().
EventEmitter is a Subject: It extends RxJS Subject, so you can subscribe to it programmatically if needed. In practice, you use it in templates via (output).
Emitting no value:
@Output() closed = new EventEmitter<void>();
// ...
this.closed.emit();Parent: (closed)="handleClose()".
Emitting complex values:
interface UserEvent {
id: number;
action: 'created' | 'updated' | 'deleted';
}
@Output() userChanged = new EventEmitter<UserEvent>();
// ...
this.userChanged.emit({ id: 1, action: 'created' });Required outputs: Angular doesn’t have a required option for outputs — a child may legitimately have no listener. Use outputs freely.
Why EventEmitter and not a callback:
EventEmitterintegrates with Angular’s template syntax, supports multiple subscribers, and works with RxJS operators. Passing a callback function would work but wouldn’t compose with the rest of Angular’s binding syntax.EventEmitteris the idiomatic tool.
Two-way communication with the Change convention
A child can expose an input and an output with a naming convention that enables [(value)] two-way binding.
export class RatingComponent {
@Input() rating = 0;
@Output() ratingChange = new EventEmitter<number>();
setRating(value: number): void {
this.rating = value;
this.ratingChange.emit(value);
}
}The output name must be the input name with Change appended.
Parent usage:
<app-rating [(rating)]="userRating"></app-rating>Angular expands this to:
<app-rating [rating]="userRating" (ratingChange)="userRating = $event"></app-rating>The [( )] syntax is sugar — it’s just an input plus an output with a specific name.
Common examples:
value+valueChangechecked+checkedChangeselected+selectedChangeopen+openChange
Why the naming convention: Angular’s compiler recognizes <input>Change as the companion output for a <input> two-way binding. It’s a simple rule that enables a lot of ergonomics.
Why two-way binding is powerful: It reduces boilerplate — the parent writes
[(value)]instead of[value]and(valueChange). Under the hood it’s still one-way down and one-way up. The convention just bundles them.
ngOnChanges — reacting to input changes
When an input changes, Angular calls ngOnChanges with a SimpleChanges object.
import { Component, Input, OnChanges, SimpleChanges } from '@angular/core';
export class UserCardComponent implements OnChanges {
@Input() userId!: number;
@Input() theme: 'light' | 'dark' = 'light';
ngOnChanges(changes: SimpleChanges): void {
if (changes['userId']) {
const { previousValue, currentValue, firstChange } = changes['userId'];
console.log('userId changed', previousValue, '→', currentValue);
if (firstChange) this.loadUser();
}
if (changes['theme']) {
// theme changed
}
}
}SimpleChanges structure:
{
[inputName]: {
previousValue: T;
currentValue: T;
firstChange: boolean;
}
}firstChange— true on the first assignmentpreviousValue— the previous value (undefined on first change)currentValue— the new value
When to use ngOnChanges:
- You need to react to specific inputs changing
- You want to distinguish first change from subsequent changes
- You need the previous value
When to use ngOnInit instead:
- You only need the initial value
- The setup logic is one-time
Order: ngOnChanges runs before ngOnInit on the first change, then again on subsequent changes.
Under OnPush change detection: ngOnChanges fires when the input reference changes. If the input is a mutable object that’s mutated in place, it won’t fire.
Why
ngOnChangesand not a setter: A setter runs every time the input is assigned, including when the reference is the same.ngOnChangesgives you the previous value and afirstChangeflag, and groups all changes into one call. It’s a better fit for reacting to input changes in a controlled way.
Inputs and the change detection model
Inputs are checked during change detection. When the parent’s binding expression changes, Angular updates the child’s input.
Reference equality: Angular compares the new input value to the old using ===. For primitives, that’s value equality. For objects and arrays, it’s reference equality — a new object with the same contents is a change; a mutated object with the same reference is not.
// Parent
items = [1, 2, 3];
addItem(): void {
this.items.push(4); // ❌ same reference — child won't see it
this.items = [...this.items, 4]; // ✅ new reference — child updates
}With OnPush change detection, the child only checks inputs when the reference changes or when marked for check. Mutating inputs (arrays, objects) won’t trigger an update.
Under Default change detection, Angular checks every component on every CD cycle, so mutated inputs still propagate eventually — but it’s inefficient and hides bugs.
The rule: Treat inputs as immutable. Never mutate them. If the parent wants to change an input, assign a new value.
Why reference equality: Angular needs a cheap way to detect changes. Reference comparison is O(1) and works for any type. Deep equality checks would be expensive. The trade-off is that you must produce new references when values change — which is also how signals, Redux, and most modern state systems work.
Common patterns
Container/presentational split:
Container components hold state, fetch data, and pass it down. Presentational components receive inputs, render, and emit outputs.
// Container
@Component({
selector: 'app-users-page',
standalone: true,
imports: [UserListComponent],
template: `
<app-user-list
[users]="users"
(selected)="onSelect($event)">
</app-user-list>
`
})
export class UsersPageComponent {
users = signal<User[]>([]);
onSelect(user: User) { /* ... */ }
}
// Presentational
@Component({
selector: 'app-user-list',
standalone: true,
template: `
@for (user of users; track user.id) {
<button (click)="selected.emit(user)">{{ user.name }}</button>
}
`
})
export class UserListComponent {
@Input() users: User[] = [];
@Output() selected = new EventEmitter<User>();
}Why this split: Container components know about services and state. Presentational components only know about their inputs and outputs. The presentational ones are reusable, testable, and easy to reason about.
Passing a callback vs an output: Prefer outputs. Callbacks are harder to test and don’t compose with the template syntax.
Reusable form control: A child input + output pair that reports value changes.
export class StarRatingComponent {
@Input() value = 0;
@Output() valueChange = new EventEmitter<number>();
setValue(n: number): void {
this.value = n;
this.valueChange.emit(n);
}
}Usage: [(value)]="rating" in the parent.
Why these patterns matter: They keep components focused. Presentational components are pure — given the same inputs, they render the same output. That makes them easy to test and safe to reuse. The container/presentational split is the oldest pattern in frontend architecture, and it still works.
A full example
A product list with selection.
// product-card.component.ts
import { Component, Input, Output, EventEmitter } from '@angular/core';
import { CurrencyPipe } from '@angular/common';
export interface Product {
id: number;
name: string;
price: number;
}
@Component({
selector: 'app-product-card',
standalone: true,
imports: [CurrencyPipe],
template: `
<div class="card" [class.selected]="selected">
<h3>{{ product.name }}</h3>
<p>{{ product.price | currency:'EUR' }}</p>
<button (click)="select.emit(product)">
{{ selected ? 'Selected' : 'Select' }}
</button>
</div>
`,
styles: `
.card { border: 1px solid #ccc; padding: 1rem; }
.card.selected { border-color: green; }
`
})
export class ProductCardComponent {
@Input({ required: true }) product!: Product;
@Input() selected = false;
@Output() select = new EventEmitter<Product>();
}// product-list.component.ts
import { Component, signal } from '@angular/core';
import { ProductCardComponent, Product } from './product-card.component';
@Component({
selector: 'app-product-list',
standalone: true,
imports: [ProductCardComponent],
template: `
<h2>Products</h2>
@for (product of products(); track product.id) {
<app-product-card
[product]="product"
[selected]="selectedId() === product.id"
(select)="onSelect($event)">
</app-product-card>
}
<p>Total selected: {{ selectedId() }}</p>
`
})
export class ProductListComponent {
products = signal<Product[]>([
{ id: 1, name: 'Keyboard', price: 79.99 },
{ id: 2, name: 'Mouse', price: 39.5 },
{ id: 3, name: 'Monitor', price: 249 }
]);
selectedId = signal<number | null>(null);
onSelect(product: Product): void {
this.selectedId.set(product.id);
}
}The parent holds the list and the selection. The child receives a product and its selected state, renders it, and emits a select event when clicked. The parent handles the event and updates state.
What this shows:
@Inputfor product and selected state@Outputfor the selection event- The child never mutates parent data — it emits and lets the parent decide
- The child is reusable — it doesn’t know the list exists
Why this shape: The card component knows nothing about the list or the selection logic — it just renders a product and reports a click. The list owns the state and decides what a click means. That separation is what makes the card reusable in another context without changes.
Complete Example Session
# ============================================
# PART 1: GENERATE THE CHILD
# ============================================
ng generate component product-card
# [ CREATE src/app/product-card/product-card.component.ts ]
# [ CREATE src/app/product-card/product-card.component.html ]
# [ CREATE src/app/product-card/product-card.component.css ]
# ============================================
# PART 2: WRITE THE CHILD
# ============================================
cat > src/app/product-card/product-card.component.ts << 'EOF'
import { Component, Input, Output, EventEmitter } from '@angular/core';
import { CurrencyPipe } from '@angular/common';
export interface Product {
id: number;
name: string;
price: number;
}
@Component({
selector: 'app-product-card',
standalone: true,
imports: [CurrencyPipe],
template: `
<div class="card" [class.selected]="selected">
<h3>{{ product.name }}</h3>
<p>{{ product.price | currency:'EUR' }}</p>
<button (click)="select.emit(product)">
{{ selected ? 'Selected' : 'Select' }}
</button>
</div>
`
})
export class ProductCardComponent {
@Input({ required: true }) product!: Product;
@Input() selected = false;
@Output() select = new EventEmitter<Product>();
}
EOF
# ============================================
# PART 3: WRITE THE PARENT
# ============================================
cat > src/app/product-list/product-list.component.ts << 'EOF'
import { Component, signal } from '@angular/core';
import { ProductCardComponent, Product } from '../product-card/product-card.component';
@Component({
selector: 'app-product-list',
standalone: true,
imports: [ProductCardComponent],
template: `
<h2>Products</h2>
@for (p of products(); track p.id) {
<app-product-card
[product]="p"
[selected]="selectedId() === p.id"
(select)="onSelect($event)">
</app-product-card>
}
<p>Selected ID: {{ selectedId() }}</p>
`
})
export class ProductListComponent {
products = signal<Product[]>([
{ id: 1, name: 'Keyboard', price: 79.99 },
{ id: 2, name: 'Mouse', price: 39.5 },
{ id: 3, name: 'Monitor', price: 249 }
]);
selectedId = signal<number | null>(null);
onSelect(product: Product): void {
this.selectedId.set(product.id);
}
}
EOF
# ============================================
# PART 4: TWO-WAY BINDING
# ============================================
cat > src/app/rating/rating.component.ts << 'EOF'
import { Component, Input, Output, EventEmitter } from '@angular/core';
@Component({
selector: 'app-rating',
standalone: true,
template: `
@for (n of [1, 2, 3, 4, 5]; track n) {
<button (click)="setValue(n)" [class.active]="n <= value">
★
</button>
}
`
})
export class RatingComponent {
@Input() value = 0;
@Output() valueChange = new EventEmitter<number>();
setValue(n: number): void {
this.value = n;
this.valueChange.emit(n);
}
}
EOF
# ============================================
# PART 5: USE TWO-WAY BINDING
# ============================================
cat > src/app/demo/demo.component.ts << 'EOF'
import { Component } from '@angular/core';
import { RatingComponent } from '../rating/rating.component';
@Component({
selector: 'app-demo',
standalone: true,
imports: [RatingComponent],
template: `
<h2>Rate us</h2>
<app-rating [(value)]="rating"></app-rating>
<p>You rated: {{ rating }}</p>
`
})
export class DemoComponent {
rating = 0;
}
EOF
# ============================================
# PART 6: SERVE
# ============================================
ng serve
# [ Local: http://localhost:4200/ ]Every pattern is exercised — inputs, outputs, required inputs, two-way binding via the Change convention, and the container/presentational split.
Why this exercise covers everything: It’s the whole communication story: parent passes data down, child emits events up, two-way binding ties a child control to parent state. Once these patterns are familiar, every component you build follows the same shape.
Quick Reference
@Input
| Form | Meaning |
|---|---|
@Input() name = 'x' | Input with default |
@Input() name!: T | Required, set by parent |
@Input({ required: true }) | Required — compile error if missing |
@Input('alias') name | Aliased input |
@Input({ alias: 'x' }) name | Modern alias syntax |
@Output
| Form | Meaning |
|---|---|
@Output() evt = new EventEmitter<T>() | Typed emitter |
@Output() evt = new EventEmitter<void>() | No payload |
this.evt.emit(value) | Send event |
Template Syntax
| Syntax | Direction |
|---|---|
[input]="expr" | Parent → child |
(output)="handler($event)" | Child → parent |
[(value)]="prop" | Two-way |
[value]="p" (valueChange)="p = $event" | Expanded two-way |
Two-Way Convention
| Input | Output |
|---|---|
value | valueChange |
checked | checkedChange |
open | openChange |
selected | selectedChange |
Lifecycle
| Hook | When |
|---|---|
constructor | Before inputs set |
ngOnChanges | Before ngOnInit, then on changes |
ngOnInit | After first ngOnChanges |
ngOnDestroy | On destroy |
SimpleChanges
| Field | Meaning |
|---|---|
previousValue | Old value (undefined first time) |
currentValue | New value |
firstChange | True on first assignment |
Required Inputs
| Syntax | Behavior |
|---|---|
@Input({ required: true }) | Compile error if missing |
@Input() name!: T | TypeScript-level requirement |
@Input() name = default | Optional, safe default |
Input Mutability
| Action | Effect |
|---|---|
| Reassign input value | ✅ triggers change |
| Mutate input object/array | ❌ no change detected under OnPush |
| Use immutable patterns | ✅ recommended |
Container vs Presentational
| Aspect | Container | Presentational |
|---|---|---|
| State | Owns | Receives |
| Services | Uses | Doesn’t |
| Inputs | Few | Many |
| Outputs | Few | Many |
| Reusability | Low | High |
Best Practices
✅ Do This:
// Type your inputs and outputs
@Input() user!: User; // ✅
@Output() select = new EventEmitter<User>(); // ✅
// Mark critical inputs as required
@Input({ required: true }) userId!: number; // ✅
// Use ngOnChanges to react to input changes
ngOnChanges(changes: SimpleChanges): void { } // ✅
// Emit new values; don't mutate inputs
this.valueChange.emit(newValue); // ✅
// Use the Change naming convention for two-way
@Input() value = 0;
@Output() valueChange = new EventEmitter<number>(); // ✅
// Treat inputs as immutable
this.items = [...this.items, newItem]; // ✅
// Use container/presentational split
// Container holds state; child renders // ✅
// Emit specific, typed values
this.selected.emit(user); // ✅❌ Don’t Do This:
// Don't read inputs in the constructor
constructor() {
console.log(this.userId); // ❌ undefined // ❌
}
// Don't mutate inputs
this.items.push(newItem); // ❌ same reference // ❌
// Don't call parent methods directly
// (no direct parent reference) // ❌
// Don't emit on every keystroke without debounce
(input)="valueChange.emit($event.target.value)" // ⚠️ consider debounce
// Don't use EventEmitter for anything other than outputs
@Input() stream = new EventEmitter<T>(); // ❌
// Don't forget to handle undefined in ngOnChanges
if (changes['x']) { } // ✅ always check // ✅
// Don't assume inputs are set in the constructor
class Child { @Input() x!: number; constructor() { this.x.toString(); } } // ❌
// Don't skip required inputs when the child needs them
@Input() user!: User; // ⚠️ use required: true when possibleCommon Pitfalls
| Pitfall | Problem | Solution |
|---|---|---|
| Reading input in constructor | Undefined | Use ngOnInit/ngOnChanges |
| Mutating input objects | No change detected | Reassign new values |
Missing EventEmitter import | Compile error | Import from @angular/core |
| Wrong output name for two-way | [(x)] doesn’t work | Use xChange |
Forgetting required | Runtime error | Use @Input({ required: true }) |
| Emitting same reference | Change not detected | Emit new values |
| Mutating input array | Child doesn’t update | Create new array |
Not checking changes | Errors on unset inputs | Check if (changes['x']) |
Real-World Examples
1. Basic input
@Input() label = '';2. Required input
@Input({ required: true }) user!: User;3. Input with default
@Input() count = 0;4. Aliased input
@Input('ariaLabel') label = '';5. Basic output
@Output() clicked = new EventEmitter<void>();6. Typed output
@Output() selected = new EventEmitter<User>();7. Emit an event
this.selected.emit(user);8. Listen in parent
<app-child (selected)="onSelect($event)"></app-child>9. Two-way binding
<app-rating [(value)]="rating"></app-rating>10. Custom two-way
@Input() value = 0;
@Output() valueChange = new EventEmitter<number>();11. React to input changes
ngOnChanges(c: SimpleChanges): void {
if (c['userId']) this.loadUser();
}12. Check first change
if (c['x']?.firstChange) { /* first time */ }13. Input array with immutable update
this.items = [...this.items, item];14. Pass data down
<app-card [user]="currentUser"></app-card>15. Send events up
<app-card (selected)="onSelected($event)"></app-card>16. Container component
@Component({ template: `<app-list [items]="items()" (pick)="onPick($event)">` })17. Presentational component
@Component({ template: `@for (i of items; track i.id) { <button (click)="pick.emit(i)">{{ i.name }}</button> }` })18. Output with payload
@Output() changed = new EventEmitter<{ id: number; value: string }>();19. Required input with alias
@Input({ required: true, alias: 'userId' }) id!: number;20. Test an output
let emitted: User | undefined;
component.selected.subscribe(u => emitted = u);
component.selected.emit(user);
expect(emitted).toBe(user);Visual: Data Flow
┌──────────────────────────────────────────────┐
│ Parent Component │
│ │
│ user = { name: 'Alice' } │
│ │
│ <app-card │
│ [user]="user" ← input │
│ (selected)="onPick($event)"> ← output │
│ </app-card> │
│ │
└──────────────────────────────────────────────┘
│ ▲
│ [user] (selected)
▼ │
┌──────────────────────────────────────────────┐
│ Child Component │
│ │
│ @Input() user!: User │
│ @Output() selected = new EventEmitter() │
│ │
│ onPick() { this.selected.emit(this.user); } │
│ │
└──────────────────────────────────────────────┘Visual: Two-Way Expansion
┌──────────────────────────────────────────────┐
│ You write: │
│ │
│ <app-rating [(value)]="rating"></app-rating>│
│ │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Angular expands to: │
│ │
│ <app-rating │
│ [value]="rating" │
│ (valueChange)="rating = $event"> │
│ </app-rating> │
│ │
└──────────────────────────────────────────────┘Visual: Lifecycle Order
┌──────────────────────────────────────────────┐
│ constructor │
│ (no inputs yet) │
│ │ │
│ ▼ │
│ ngOnChanges (first) │
│ (inputs now set) │
│ │ │
│ ▼ │
│ ngOnInit │
│ (safe to use inputs) │
│ │ │
│ ▼ │
│ ngOnChanges (subsequent) │
│ (input changed) │
│ │ │
│ ▼ │
│ ngOnDestroy │
│ │
└──────────────────────────────────────────────┘Visual: SimpleChanges
┌──────────────────────────────────────────────┐
│ ngOnChanges(changes) │
│ │
│ changes = { │
│ userId: { │
│ previousValue: undefined, ← first time │
│ currentValue: 42, │
│ firstChange: true │
│ } │
│ } │
│ │
│ On next change: │
│ │
│ previousValue: 42, │
│ currentValue: 99, │
│ firstChange: false │
│ │
└──────────────────────────────────────────────┘Visual: Container / Presentational
┌──────────────────────────────────────────────┐
│ Container │
│ ─ owns state │
│ ─ uses services │
│ ─ passes data down │
│ ─ handles events │
│ │
│ @Component({ │
│ template: ` │
│ <app-list │
│ [items]="items()" │
│ (select)="onSelect($event)"> │
│ </app-list> │
│ ` │
│ }) │
│ │
└──────────────────────────────────────────────┘
│
│ inputs / outputs
▼
┌──────────────────────────────────────────────┐
│ Presentational │
│ ─ pure inputs │
│ ─ emits outputs │
│ ─ no services │
│ ─ reusable │
│ │
│ @Component({ │
│ template: ` │
│ @for (i of items; track i.id) { │
│ <button (click)="select.emit(i)"> │
│ {{ i.name }} │
│ </button> │
│ } │
│ ` │
│ }) │
│ │
└──────────────────────────────────────────────┘Visual: Input Mutability
┌──────────────────────────────────────────────┐
│ Reassign (recommended) │
│ │
│ this.items = [...this.items, newItem]; │
│ │
│ → new reference │
│ → child sees change │
│ │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│ Mutate (avoid) │
│ │
│ this.items.push(newItem); │
│ │
│ → same reference │
│ → child doesn't update under OnPush │
│ │
└──────────────────────────────────────────────┘Visual: Output Naming for Two-Way
┌──────────────────────────────────────────────┐
│ Child: │
│ │
│ @Input() value │
│ @Output() valueChange │
│ │ │
│ │ same base name + "Change" │
│ ▼ │
│ Parent: │
│ │
│ [(value)]="prop" │
│ │
└──────────────────────────────────────────────┘Visual: Communication Checklist
┌──────────────────────────────────────────────┐
│ Parent passes data? → @Input │
│ Child sends events? → @Output │
│ Both? → [(value)] │
│ React to input? → ngOnChanges │
│ Use input on init? → ngOnInit │
│ Mark as required? → @Input required │
│ Alias for template? → @Input('name') │
│ Reusable component? → container/present. │
│ │
└──────────────────────────────────────────────┘Summary
| Concept | Meaning |
|---|---|
@Input | Parent → child data |
@Output | Child → parent events |
EventEmitter | Emits output values |
ngOnChanges | Reacts to input changes |
SimpleChanges | Diff of input changes |
| Two-way binding | [(value)] sugar |
xChange convention | Enables two-way |
| Required input | @Input({ required: true }) |
| Alias | @Input('name') |
| Container/presentational | Split of state and display |
Key takeaways:
@Inputreceives data from the parent;@Outputemits events to the parent- The template syntax mirrors DOM bindings —
[input],(output),[(twoWay)] - Inputs are set after the constructor — use
ngOnInitorngOnChangesto react ngOnChangesgives you previous and current values, plus afirstChangeflag- Treat inputs as immutable — reassign, don’t mutate, especially under
OnPush - Two-way binding uses the
x+xChangenaming convention - Mark critical inputs required with
@Input({ required: true }) - Alias inputs when you want a different template name
EventEmitteris aSubject— typed, testable, composable- Split components into containers (state) and presentational (display)
- Children never reach into parents — they emit events and let the parent decide
- Typed inputs and outputs make components self-documenting
Remember: Component communication is one-way down, one-way up. @Input brings data in; @Output sends events out. The parent owns the state and decides what events mean. The child receives inputs, renders, and emits — nothing more. That discipline is what keeps components reusable, testable, and easy to reason about. Every Angular app is a tree of components passing data through these two decorators. Get them right and the rest of the framework follows.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!