As an Angular developer, you’ve likely used lifecycle hooks such as ngOnChanges, ngOnInit, and ngOnDestroy. With the advent of Zoneless and Signals, we can use better, more readable options.
Let’s check them out:
Replacing ngOnChanges with computed()
Previously, ngOnChanges was required to react to @Input changes and update derived state. With Signal inputs, computed handles this automatically, lazily, and without side effects.
Here is an example with before/after code.
Before — ngOnChanges:
@Component({...})
export class PricingComponent implements OnChanges {
@Input() price = 0;
totalPrice = 0;constructor(private taxService: TaxService) {}
ngOnChanges(changes: SimpleChanges) {
if (changes['price']) {
// Calling the service when the input updates
this.totalPrice = this.taxService.calculateTotal(this.price);
}
}
}
After — computed:
@Component({...})
export class PricingComponent {
price = input(0);
private taxService = inject(TaxService);// Calling the service when the input updates
totalPrice = computed(() => this.taxService.calculateTotal(this.price()));
}
Using Signals is not only more performant, but it’s also more concise and readable.
Rethinking ngOnInit
ngOnInit was often used as a safe place to initialize data once inputs were available. With Signals and modern reactivity, initialization can often happen declaratively at the property level.
Get Alain Chautard’s stories in your inbox
Join Medium for free to get updates from this writer.
Before — ngOnInit:
@Component({...})
export class UserComponent implements OnInit {
@Input() userId!: string;
userData!: User;constructor(private userService: UserService) {}
ngOnInit() {
// Relying on ngOnInit to ensure userId is ready
this.userData = this.userService.getUserSync(this.userId);
}
}
After — signal-based:
@Component({...})
export class UserComponent {
userId = input.required();
private userService = inject(UserService);// Derives the user data reactively without needing a hook
userData = computed(() => this.userService.getUserSync(this.userId()));
}
The signal-based option is even better as it would react to subsequent updates ot the userId input, if that ever happens.
Retiring ngOnDestroy
Manually storing Subscription arrays or other techniques inside ngOnDestroy is no longer necessary thanks to takeUntilDestroyed().
Before — manual subscription and unsubscription:
@Component({...})
export class AlertComponent implements OnDestroy {private sub: Subscription;
constructor(private alertService: AlertService) {
this.sub = this.alertService.alerts$
.subscribe(alert => console.log(alert));
}
ngOnDestroy() {
this.sub.unsubscribe();
}
}
After — takeUntilDestroyed:
@Component({...})
export class AlertComponent {constructor(private alertService: AlertService) {
this.alertService.alerts$
.pipe(takeUntilDestroyed())
.subscribe(alert => console.log(alert));
}
}
Here again, the approach is more concise and readable. And, of course, replacing RxJs entirely with Signals would simplify this even further (I have some good tips about that Signal migration here).
As we can see, lifecycle hooks can be replaced with a more maintainable option most of the time. Lifecycle hooks aren’t dead, but they are now specialized tools rather than everyday necessities (e.g., you still need ngAfterViewInit for direct DOM/canvas manipulation).
My name is Alain Chautard. I am a Google Developer Expert in Angular and a consultant and trainer at Angular Training, where I help development teams learn and become proficient with Angular / React / JavaScript.
If you need any help learning web technologies, feel free to get in touch!
If you enjoyed this article, please clap for it or share it. Your help is always appreciated. You can also subscribe to my articles and YouTube video page.

