Child to parent communication flow in Angular - Performance & Optimization

Performance: Child to parent communication flow

MEDIUM IMPACT

This affects interaction responsiveness and rendering updates when child components send data or events to parent components.

Passing data or events from a child component to its parent

Angular

import { Component, Output, EventEmitter } from '@angular/core';
@Component({ selector: 'child-comp', template: `<button (click)="clicked.emit()">Click</button>` })
export class ChildComp {
  @Output() clicked = new EventEmitter<void>();
}

// Parent template: <child-comp (clicked)="parentMethod()"></child-comp>

Using @Output with EventEmitter leverages Angular's event system, minimizing change detection overhead and avoiding passing function references.

📈 Performance GainReduces unnecessary change detection cycles and reflows, improving interaction responsiveness.

Passing data or events from a child component to its parent

Angular

import { Component, Input } from '@angular/core';
@Component({ selector: 'child-comp', template: `<button (click)="notifyParent()">Click</button>` })
export class ChildComp {
  @Input() parentCallback!: () => void;
  notifyParent() {
    this.parentCallback();
  }
}

// Parent template: <child-comp [parentCallback]="parentMethod"></child-comp>

Passing functions via @Input causes Angular to treat the function as a new reference on each change detection, triggering unnecessary re-renders and change detection cycles.

📉 Performance CostTriggers multiple change detection cycles and can cause unnecessary reflows if parent updates heavy DOM.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Passing function via @Input	Triggers parent and child change detection	Multiple reflows if parent updates DOM	Higher paint cost due to unnecessary updates	[X] Bad
Using @Output EventEmitter	Triggers minimal change detection scoped to parent	Single reflow if DOM changes	Lower paint cost with targeted updates	[OK] Good

Rendering Pipeline

When a child component emits an event, Angular triggers change detection starting from the parent component, updating the DOM only if necessary.

→Change Detection

→Layout

→Paint

⚠️ BottleneckChange Detection can be expensive if many components re-check unnecessarily.

Core Web Vital Affected

INP

This affects interaction responsiveness and rendering updates when child components send data or events to parent components.

Optimization Tips

1Use @Output EventEmitter for child-to-parent communication to limit change detection scope.

2Avoid passing functions as @Input to prevent unnecessary re-renders.

3Monitor change detection cycles in DevTools Performance panel to identify inefficiencies.

Performance Quiz - 3 Questions

Which Angular pattern minimizes unnecessary change detection when a child notifies its parent?

A Directly modifying parent variables from child

B Passing a callback function via @Input

C Using @Output with EventEmitter

D Using a shared service with BehaviorSubject

DevTools: Performance

How to check: Record a performance profile while interacting with the child component event. Look for change detection cycles and layout recalculations.

What to look for: Excessive change detection or layout thrashing indicates inefficient child-to-parent communication.

Practice

1. What is the main Angular feature used for communication from a child component to its parent?

easy

A. Using ViewChild to access parent methods

B. Using @Input to send data

C. Using services with HttpClient

D. Using @Output with EventEmitter

Solution

1. Step 1: Understand child to parent communication

   Child components send data or events to parents using Angular's event system.

2. Step 2: Identify Angular feature for this

   @Output decorator with EventEmitter allows child to emit events the parent listens to.

3. Final Answer:

   Using @Output with EventEmitter -> Option D

4. Quick Check:

   Child to parent = @Output + EventEmitter [OK]

Hint: Child emits events with @Output and EventEmitter [OK]

Common Mistakes:

• Confusing @Input as child to parent communication
• Thinking services are needed for simple child to parent
• Using ViewChild to call parent methods directly

2. Which of the following is the correct syntax to declare an event emitter in a child component?

easy

A. notify = new EventEmitter<string>();

B. @Input() notify = new EventEmitter<string>();

C. @Output() notify = new EventEmitter<string>();

D. @Output notify = EventEmitter<string>();

Solution

1. Step 1: Recall correct decorator and initialization

   Event emitters must be decorated with @Output() and initialized with new EventEmitter<type>().

2. Step 2: Check each option

   @Output() notify = new EventEmitter<string>(); correctly uses @Output() and initializes the emitter. Others miss decorator, use wrong decorator, or wrong syntax.

3. Final Answer:

   @Output() notify = new EventEmitter<string>(); -> Option C

4. Quick Check:

   @Output() + new EventEmitter() = correct syntax [OK]

Hint: Always use @Output() with new EventEmitter() [OK]

Common Mistakes:

• Using @Input instead of @Output
• Forgetting parentheses after @Output
• Not initializing EventEmitter with new keyword

3. Given this child component code:

@Output() change = new EventEmitter<number>();
updateValue() {
  this.change.emit(42);
}

What will the parent component receive when updateValue() is called?

medium

A. An event with value 42

B. An event with value 'updateValue'

C. No event emitted

D. An error because emit needs a string

Solution

1. Step 1: Understand what emit does

   The emit method sends the given value (here 42) as an event payload to the parent.

2. Step 2: Check the emitted value type

   The emitter is typed as number and emits 42, so the parent receives 42.

3. Final Answer:

   An event with value 42 -> Option A

4. Quick Check:

   emit(42) sends 42 to parent [OK]

Hint: emit(value) sends that value to parent [OK]

Common Mistakes:

• Assuming emit sends method name instead of value
• Thinking emit requires string only
• Believing no event is sent without explicit subscription

4. Identify the error in this child component code snippet:

@Output notify = new EventEmitter<string>();
send() {
  this.notify.emit('hello');
}

medium

A. Missing parentheses after @Output decorator

B. EventEmitter should not have a type parameter

C. emit method cannot send strings

D. notify should be private

Solution

1. Step 1: Check @Output decorator syntax

   The @Output decorator requires parentheses: @Output().

2. Step 2: Verify other parts

   Type parameter on EventEmitter is allowed, emit can send strings, and notify can be public.

3. Final Answer:

   Missing parentheses after @Output decorator -> Option A

4. Quick Check:

   @Output() needs parentheses [OK]

Hint: Always write @Output() with parentheses [OK]

Common Mistakes:

• Omitting parentheses after @Output
• Thinking EventEmitter can't have types
• Assuming emit only accepts numbers

5. You want a child component to send a complex object to its parent when a button is clicked. Which approach correctly implements this?

Child component:
@Output() sendData = new EventEmitter<{id:number, name:string}>();

onClick() {
  const data = {id: 1, name: 'Test'};
  this.sendData.emit(data);
}

Parent component template:
<app-child (sendData)="handleData($event)"></app-child>

What should the parent component's handleData method look like?

hard

A. handleData(data: number) { console.log(data); }

B. handleData(data: {id: number; name: string}) { console.log(data.name); }

C. handleData(event: string) { console.log(event); }

D. handleData() { console.log('No data received'); }

Solution

1. Step 1: Understand emitted data type

   The child emits an object with id and name properties.

2. Step 2: Match parent handler parameter

   The parent method must accept an object matching the emitted type to access properties like name.

3. Final Answer:

   handleData(data: {id: number; name: string}) { console.log(data.name); } -> Option B

4. Quick Check:

   Parent handler param matches emitted object type [OK]

Hint: Parent handler param matches emitted object shape [OK]

Common Mistakes:

• Ignoring event parameter in handler
• Using wrong parameter type in handler
• Not accessing object properties correctly