Componentsintermediate
ngOnChanges Deep Dive
Understand exactly when ngOnChanges fires, what SimpleChanges contains, and its limitations.
ngOnChanges is the hook interviewers use to test whether you understand reference equality in JavaScript, because it only fires when an @Input() is reassigned to a new reference (or a new primitive value) — not when you mutate a nested property of an object or array in place. This trips up almost everyone the first time they rely on it to detect a change to items.push(newItem) and nothing happens.
It's like a mailroom that only notifies you when a new envelope arrives with a new tracking number — if someone quietly slips extra pages into an envelope you already received, the mailroom keeps quiet.
Key Concepts
1
When it does fire, Angular passes a SimpleChanges object keyed by input property name, where each entry is a SimpleChange containing previousValue, currentValue, and firstChange. This lets you write logic that behaves differently on the very first change versus subsequent ones, which is useful for avoiding redundant work on initialization.
SimpleChangesSimpleChangepreviousValuecurrentValuefirstChange
2
A good interview answer distinguishes ngOnChanges from ngDoCheck: ngOnChanges is cheap and targeted (only reacts to bound input changes) while ngDoCheck runs on every change detection cycle regardless of cause and requires you to implement your own diffing, making it powerful but expensive if misused.
ngOnChangesngDoCheck
3
In modern Angular using signal-based inputs, much of what ngOnChanges was used for is now handled more naturally with effect() reacting to a signal's value, since signals track fine-grained dependencies rather than relying on reference-equality checks across an entire object.
ngOnChangeseffect()