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<number>(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.

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<string>();
  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).