React Hooks in Angular?! Share Lifecycle Methods Between Components in Angular

On this page · 8 sections

This piece was co-authored with Lars Gyrup Brink Nielsen. His contributions to the research and drafting process were essential. Be sure to check him out.

Over the last few years, frameworks such as React and Vue have introduced utilities for reusing lifecycle logic. How does that work in practice?

Rest assured, this post is about Angular—just bear with me for a moment.

Suppose you need a component that tracks the dimensions of the browser window. In that case, you might implement something along these lines:

const App = () => {
  const [height, setHeight] = useState(window.innerHeight);
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    function onResize() {
      setHeight(window.innerHeight);
      setWidth(window.innerWidth);
    }

    window.addEventListener('resize', onResize);

    return () => window.removeEventListener('resize', onResize);
  }, []);

  return <p>The window is {height}px high and {width}px wide</p>
}

Vue

<!-- App.vue -->
<template>
    <p>The window is {{height}}px high and {{width}}px wide</p>
</template>

<script setup>
import {ref, onMounted, onUnMounted} from 'vue';

const height = ref(window.innerHeight);
const width = ref(window.innerWidth);

function onResize() {
  height.value = window.innerHeight;
  width.value = window.innerWidth;
}

onMounted(() => {
  window.addEventListener('resize', onResize);
});

onUnMounted(() => {
  window.removeEventListener('resize', onResize);
});
</script>

Enjoy seeing how different frameworks handle the same problem? You might be interested in my upcoming book, "The Framework Field Guide", which covers React, Angular, and Vue side by side.

That approach works fine when you only have one component to worry about. But imagine needing to share that same window handling logic across several components.

Sure, you could duplicate the code in each component, or even pull out functions to manage adding and removing event listeners. Both options, however, feel awkward. This is exactly why React has Hooks and Vue has Composition API.

const useWindowSize = () => {
  const [height, setHeight] = useState(window.innerHeight);
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    function onResize() {
      setHeight(window.innerHeight);
      setWidth(window.innerWidth);
    }

    window.addEventListener('resize', onResize);

    return () => window.removeEventListener('resize', onResize);
  }, []);

    return {height, width};  
}

const App = () => {
  const {height, width} = useWindowSize();
  return <p>The window is {height}px high and {width}px wide</p>
}

Vue

// useWindowSize.ts
import {ref, onMounted, onUnMounted} from 'vue';

export const useWindowSize = () => {
  const height = ref(window.innerHeight);
  const width = ref(window.innerWidth);

  function onResize() {
    height.value = window.innerHeight;
    width.value = window.innerWidth;
  }

  onMounted(() => {
    window.addEventListener('resize', onResize);
  });

  onUnMounted(() => {
    window.removeEventListener('resize', onResize);
  });

  return {height, width};
}

<!-- App.vue -->
<template>
    <p>The window is {{height}}px high and {{width}}px wide</p>
</template>

<script setup>
import {useWindowSize} from './useWindowSize';

const {height, width} = useWindowSize();
</script>

As a result, the useWindowSize logic — lifecycle methods included — can be shared across multiple components.

How does this translate to Angular, though? Is there a way to reuse logic, along with lifecycle hooks, without duplicating code manually?

The solution: a shared base component class that you can extend.

Here’s what we’ll cover in this guide:

Let’s start with the premise that you understand classes, but might not be clear on what class extension—or inheritance—involves.

To illustrate quickly, imagine we have this JavaScript class:

class HelloMessage {
    message = "Hello";
    name = "";

  constructor(name) {
    this.name = name;
  }

  sayHi() {
    console.log(`${this.message} ${this.name}`);
  }
}

const messageInstance = new HelloMessage("Corbin");
messageInstance.sayHi(); // Will log "Hello Corbin"

There’s a lot packed into this class:

A pair of fields: message alongside name
A constructor that accepts a parameter, assigning name a fresh value
A single function named sayHi

Instantiating this class triggers the constructor, returning an object that carries every property and method belonging to HelloMessage as an "instance" of that type.

Suppose we now want the sayHi logic to be shared across several different classes simultaneously.

That rings a bell, doesn’t it?

One option is to define a separate class exposing sayHi:

class BaseHelloMessage {
    message = "Hey there!";
    name = "";

  constructor(name) {
    this.name = name;
  }

  sayHi() {
    console.log(`${this.message} ${this.name}`);
  }
}

With extends, we are now able to define several classes that share the exact same properties and methods found in BaseHelloMessage:

class HelloMessage extends BaseHelloMessage {
}

const helloMsgInstance = new HelloMessage("Corbin");
// Inhereted from "BaseHelloMessage"
helloMsgInstance.sayHi();

class OtherHelloMessage extends BaseHelloMessage {
}

const otherHelloMsgInstance = new OtherHelloMessage("Corbin");
// Also inhereted from "BaseHelloMessage"
console.log(otherHelloMsgInstance.name);

Unfortunately, message currently holds the value "Hey there!", which is not the desired initial state for OtherHelloMessage. To fix this, we can override the message property so it becomes "Hi-a!"

This can be achieved straightforwardly by applying an "Override":

// `sayHi` will output "Hey there! Corbin"
class HelloMessage extends BaseHelloMessage {
}

// `sayHi` will output "Hi-a! Corbin"
class OtherHelloMessage extends BaseHelloMessage {
  message = "Hi-a!";
}

You can do this fine in JavaScript, though TypeScript will nudge you with a minor type error:

TS4114: An 'override' modifier is required on this member because it overrides a property from the base class 'BaseComponent'.

All it takes to fix this is adjusting OtherHelloMessage like so:

// `sayHi` will output "Hi-a! Corbin"
class OtherHelloMessage extends BaseHelloMessage {
  override message = "Hi-a!";
}

Now that we've covered class extensions, it's time to apply them within Angular!

Suppose we need a class in Angular that captures the current window size and presents it to the user:

@Component({
  template: `
    <p>The window is {{height}}px high and {{width}}px wide</p>
  `,
  selector: 'app-root'
})
class AppComponent implements OnInit, OnDestroy {
  height = window.innerHeight;
  width = window.innerWidth;

  // This needs to be an arrow function
  onResize = () => {
    this.height = window.innerHeight;
    this.width = window.innerWidth;
  }

  ngOnInit() {
    window.addEventListener('resize', this.onResize);
  }

  ngOnDestroy() {
    window.removeEventListener('resize', this.onResize);
  }
}

Even so, the goal remained to reuse this window size logic across several components.

Fortunately, a classic Object-Oriented Programming (OOP) approach lets us accomplish that: we define a base class for later extension.

Let’s test this out right away by making a BaseComponent class:

class BaseComponent implements OnInit, OnDestroy {
  height = window.innerHeight;
  width = window.innerWidth;

  // This needs to be an arrow function
  onResize = () => {
    this.height = window.innerHeight;
    this.width = window.innerWidth;
  }

  ngOnInit() {
    window.addEventListener('resize', this.onResize);
  }

  ngOnDestroy() {
    window.removeEventListener('resize', this.onResize);
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>The window is {{height}}px high and {{width}}px wide</p>
  `,
})
class AppComponent extends BaseComponent {
}

At first glance, this appears to be right—but instead, we end up with a compiler error:

Error: src/app/app.module.ts:5:7 - error NG2007: Class is using Angular features but is not decorated. Please add an explicit Angular decorator.

The solution here is straightforward—just do what the TypeScript compiler warning tells us. Since BaseComponent behaves almost like a real component, we can define it as one:

@Component({
  template: '',
  selector: 'base-component'
})
class BaseComponent implements OnInit, OnDestroy {
  height = window.innerHeight;
  width = window.innerWidth;

  // This needs to be an arrow function, otherwise `this` will bind to the Window
  // For more, see: https://twitter.com/crutchcorn/status/1530104879271645184
  onResize = () => {
    this.height = window.innerHeight;
    this.width = window.innerWidth;
  }

  ngOnInit() {
    window.addEventListener('resize', this.onResize);
  }

  ngOnDestroy() {
    window.removeEventListener('resize', this.onResize);
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>The window is {{height}}px high and {{width}}px wide</p>
  `,
})
class AppComponent extends BaseComponent {
}

This addresses the issue, so AppComponent now responds to resizing just as intended.

But, as you observe, although BaseComponent carries the implements keyword, AppComponent omits it. Even though this omission might not be strictly mandatory in current Angular releases, my own recommendation is to keep it included.

@Component({
  selector: 'app-root',
  template: `
    <p>The window is {{height}}px high and {{width}}px wide</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit, OnDestroy {
}

Reviewing the AppComponent code makes it straightforward to identify which lifecycle methods belong to the extended class versus the component itself.

Now that BaseComponent is extendible, a different annoyance has surfaced because of the @Component decorator: we've introduced a new component that might unintentionally appear in another component's template.

Take a template like this, for instance:

<base-component></base-component>

No compiler error would be raised, yet we'd end up with an unneeded piece of code executing. The ideal scenario is for BaseComponent to keep using its lifecycle methods while avoiding the creation of a fresh template element.

The good news is this works, starting from Angular 9; just drop the selector property from BaseComponent's @Component decorator, and no new tag gets registered.

@Component({
  template: ''
})
class BaseComponent implements OnInit, OnDestroy {
  // ...
}

This addresses a single issue, yet the @Component approach still carries a remaining drawback: the BaseComponent has to be listed in the declarations of an NgModule. Without that step, the compiler will throw the error shown below:

BaseComponent is not declared in any Angular module

One way to handle this is by importing BaseComponent into an NgModule. Another option is to declare BaseComponent as an abstract class instead.

@Component({
  template: ''
})
abstract class BaseComponent implements OnInit, OnDestroy {
  // ...
}

`@Injectable` serves as a substitute for an abstract class

Starting with Angular 10, your BaseComponent can be declared using @Injectable. This approach avoids the requirement of making a component class abstract, and it works because Injectables don't need to be registered in any module regardless:

@Injectable()
class BaseComponent implements OnInit, OnDestroy {
  // ...
}

With BaseComponent now declared as @Injectable rather than @Component, you’d think AppComponent would require some adjustment—yet that’s not the case at all.

@Injectable()
class BaseComponent implements OnInit {
  ngOnInit() {
    console.log('I AM BASE COMPONENT');
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent {
}

Even though the Angular team explicitly endorses @Injectable, swapping it for @Component is quite messy. The reason is that Angular's @Injectable instances lack lifecycle support unless a Component inherits from them.

Therefore, we'll go with the abstract class approach.

As noted in our earlier discussion of base classes, you can override the base class's methods and properties.

Lifecycle hooks follow the same rule, given that they're simply methods defined on the component instance.

@Component({
  template: ''
})
abstract class BaseComponent implements OnInit {
  ngOnInit() {
    console.log('I AM BASE COMPONENT');
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit {
  override ngOnInit() {
    console.log("And I am the AppComponent")
  }
}

The catch, of course, is that AppComponent's ngOnInit overwrites the ngOnInit from BaseComponent, so the original logic never runs. But what if the goal is to extend the existing behavior of ngOnInit, not swap it out completely?

Fortunately, super comes to the rescue here. It points to the base class, letting you invoke the overridden method from within your new version:

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit {
  override ngOnInit() {
    // This will log `I AM BASE COMPONENT`
    super.ngOnInit();
    console.log("And I am the AppComponent")
  }
}

Although the window variable is available globally in a browser, leveraging it inside an Angular app that's server-side rendered will cause an exception to be raised.

window is not defined

Angular's dependency injection lets you bypass this issue: inject a document instance straight into BaseComponent, then reach the window via defaultView.

@Component({
  template: ''
})
abstract class BaseComponent implements OnInit, OnDestroy {
  window!: Window;
  constructor(@Inject(DOCUMENT) private document: Document) {
    this.window = document.defaultView!;
  }
}

For this reason, tapping into the document and window instances within an Angular component is best achieved this way, even when the app isn't using SSR.

Fortunately, extending Angular component classes gives you this capability without any extra setup:

import {Component, Inject, Injectable, OnDestroy, OnInit} from '@angular/core';
import {DOCUMENT} from "@angular/common";

@Component({
  template: ''
})
abstract class BaseComponent implements OnInit, OnDestroy {
  window!: Window;
  constructor(@Inject(DOCUMENT) private document: Document) {
    this.window = document.defaultView!;
  }

  height = this.window.innerHeight;
  width = this.window.innerWidth;

  // This needs to be an arrow function
  onResize = () => {
    this.height = this.window.innerHeight;
    this.width = this.window.innerWidth;
  }

  ngOnInit() {
    this.window.addEventListener('resize', this.onResize);
  }

  ngOnDestroy() {
    this.window.removeEventListener('resize', this.onResize);
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>The window is {{height}}px high and {{width}}px wide</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit, OnDestroy {
}

Customizing `constructor` logic

When you extend a class—whether in Angular or plain JavaScript—overriding the constructor demands an explicit call to super().

class BaseClass {
  name = "";
  constructor() {
    name = "Frank";
  }
}

class AppClass extends BaseClass {
    constructor() {
        // This is required
    super();
    }
}

If you skip the super call, this error is what you will encounter:

Uncaught ReferenceError: must call super constructor before using 'this' in derived class constructor

Just as with the constructor, if you override it in a class component, you’re also required to invoke super there.

@Component({
  template: ''
})
abstract class BaseComponent {
  name = "";
  constructor() {
    this.name = "Kevin";
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>{{name}}</p>
  `,
})
class AppComponent extends BaseComponent {
  constructor() {
    super();
    this.name = "Corbin";
  }
}

When a base component relies on dependency injection, the situation becomes considerably more tangled.

@Component({
  template: ''
})
abstract class BaseComponent {
  window!: Window;
  constructor(@Inject(DOCUMENT) private document: Document) {
    this.window = document.defaultView!;
  }

  // ...
}

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent {
  // This code doesn't work. Read on to learn why
  constructor() {
    super();
  }
}

Since the super method requires the exact same arguments coming from dependency injection, we end up running into this error:

TS2554: Expected 1 arguments, but got 0.
  app.component.ts(8, 15): An argument for 'document' was not provided.

To address this, we must supply document to BaseComponent, sourced from the dependency injection of a fresh AppComponent instance:

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit {
  // This code doesn't work. Read on to learn why
  constructor(@Inject(DOCUMENT) private document: Document) {
    super(document);
    console.log(document.body);
  }
}

Unfortunately, that approach won't work either!

Just as we were required to add override to the lifecycle methods in our AppComponent, our constructor demands the same treatment. Without it, the following error will be thrown:

TS4115: This parameter property must have an 'override' modifier because it overrides a member in base class 'BaseComponent'.

Here’s how that updated code could appear in practice:

@Component({
  template: ''
})
abstract class BaseComponent implements OnInit {
  constructor(@Inject(DOCUMENT) private document: Document) {}
  ngOnInit() {
    console.log(document.title);
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit {
  constructor(@Inject(DOCUMENT) private override document: Document) {
    super(document);
    console.log(document.body);
  }
}

It's important to note that the example above still fails to compile. The compiler throws an error for the given code:

TS2415: Class 'AppComponent' incorrectly extends base class 'BaseComponent'.
   Types have separate declarations of a private property 'document'.

The fix is straightforward: expose the BaseComponent's constructor properties as public rather than keeping them private:

@Component({
  template: ''
})
abstract class BaseComponent implements OnInit {
  constructor(@Inject(DOCUMENT) public document: Document) {}
  ngOnInit() {
    console.log(document.title);
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit {
  constructor(@Inject(DOCUMENT) public override document: Document) {
    super(document);
    console.log(document.body);
  }
}

Be sure the override property stays inside the AppComponent constructor; missing that will cause errors.

As another option, drop parameter properties from BaseComponent entirely and simply avoid assigning a visibility modifier like public or private to the field, for instance:

@Component({
  template: ''
})
abstract class BaseComponent implements OnInit {
  private document: Document;

  constructor(@Inject(DOCUMENT) document: Document) {
    this.document = document;
  }

  ngOnInit() {
    console.log(document.title);
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent implements OnInit {
  constructor(@Inject(DOCUMENT) document: Document) {
    super(document);
    console.log(document.body);
  }
}

The `constructor` isn't mandatory for Dependency Injection

Our earlier solution functions, but it forces you to revisit and modify each derived class whenever you introduce another dependency to the parent class.

Angular 14 changes that by adding the inject function, making constructor-based injection obsolete. This new API is simple to grasp: swap out constructor injection for an inject call placed in a property initializer:

import { inject } from '@angular/core';

@Component({
  template: ''
})
abstract class BaseComponent {
  // The `Document` type annotation is optional as it can be inferred by the `inject` function
  private document: Document = inject(DOCUMENT);

  window!: Window = this.document.defaultView;

  // No constructor needed as we use property injection instead of constructor injection

  // ...
}

As a result, the AppComponent class becomes far more lightweight:

@Component({
  selector: 'app-root',
  template: `
    <p>Test</p>
  `,
})
class AppComponent extends BaseComponent {
  // This code now works as the base class doesn't have constructor parameters anymore
  constructor() {
    super();
  }
}

Having just walked through the process of extending base classes in Angular to reuse lifecycle hooks, let me turn the tables:

You should steer clear of base classes in Angular.

Why?

Angular specialists frequently point out that relying on a base class is fragile and challenging to keep up.

Consider a base component initially without dependency injection—what happens if DI becomes necessary later?

You'd be forced to update each and every subclass that inherited from it.

Likewise, adding a lifecycle hook you intend to override later can trigger complications depending on the sequence of operations.

Even though the inject function addresses part of the issue, it quietly adds a fresh dependency, which could:

Cause runtime errors when providers are absent
Complicate or hinder testing for the same cause

Additionally, several alternative, more robust ways exist to structure this code.

Fixing things the right way

Modern approaches to writing the WindowSize code handle maintainability concerns more effectively.

Here are two distinct strategies for tackling the problem:

A straightforward approach swapping lifecycle hooks for explicit function calls
A more idiomatic Angular solution leveraging RxJS

The naïve way to fix the issue

A straightforward remedy for several lifecycle method maintainability issues involves an @Injectable class registered per component—this lets the constructor establish side effects while the Injectable's ngOnDestroy cleanup method tears them down:

Keep in mind, Injectables lack ngOnInit!

@Injectable()
class WindowSizeService implements OnDestroy {
  private window!: Window;
  height = 0;
  width = 0;

  constructor(@Inject(DOCUMENT) document: Document) {
    this.window = document.defaultView!;
    this.height = this.window.innerHeight
    this.width = this.window.innerWidth
    window.addEventListener('resize', this.onResize);
  }

  onResize = () => {
    this.height = window.innerHeight;
    this.width = window.innerWidth;
  }

  ngOnDestroy() {
    window.removeEventListener('resize', this.onResize);
  }
}

@Component({
  selector: 'app-root',
  template: `
    <p>The window is {{windowSize.height}}px high and {{windowSize.width}}px wide</p>
  `,
  providers: [WindowSizeService]
})
class AppComponent {
  constructor(public windowSize: WindowSizeService) {
  }
}

While this code runs without errors, it brings its own set of maintainability concerns. Any additional arguments you need to feed into addListeners or removeListeners will reintroduce the exact refactoring headache you were trying to avoid.

Moreover, mutating height and width directly does trigger change detection, but tracing the exact moment those mutations occur becomes nearly impossible. What we really need is a mechanism to observe those changes as they happen.

Wouldn't it be great if Angular offered a way to subscribe to a sequence of updates, say, through some sort of... Observable?

Well, it does!

Fixing the code the Angular way

Mutable properties might be sufficient, but they're hardly ideal. Angular ships with rxjs built-in, so let's use that to build an observable instead.

For scenario of listening to DOM events, RxJS provides the fromEvent utility. By chaining it with a map operator, we can turn it into a proper Observable.

import {fromEvent, debounceTime, map, Subject, takeUntil, Observable} from 'rxjs';

interface WindowSize {
  readonly height: number;
  readonly width: number;
}

@Injectable()
class WindowSizeService implements OnDestroy {
  private destroy$ = new Subject<void>();

  size$: Observable<WindowSize>;

  constructor(@Inject(DOCUMENT) document: Document) {
    const window = document.defaultView!;
    this.size$ = fromEvent(window, 'resize').pipe(
      debounceTime(50),
      map(() => ({
        height: window.innerHeight,
        width: window.innerWidth,
      })),
      startWith({
        height: window.innerHeight,
        width: window.innerWidth,
      }),
      takeUntil(this.destroy$)
    );
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

The configuration here is far simpler and feels much more natural to Angular.

A nice bonus is that an AsyncPipe can now be used to subscribe to updates from the size$ observable:

@Component({
  selector: 'app-root',
  template: `
    <p *ngIf="windowSize.size$ | async as size">The window is {{size.height}}px high and {{size.width}}px wide</p>
  `,
  providers: [WindowSizeService]
})
class AppComponent {
  windowSize = inject(WindowSizeService);
}

That wraps it up. Hopefully, this gave you a useful perspective on expanding your component logic.

Angular is far from done evolving here—there's a fresh hostDirectives API on the horizon for sharing logic across components.

By the way, if you're eager to dig deeper into Angular, or if you've used it for a while and are curious about React or Vue without starting over, we've got something for you.

Take a look at my complimentary book, "The Framework Field Guide," which covers React, Angular, and Vue simultaneously.

Corbin Crutchley

Writes about Change Detection, Signals, Components. Active 2021–2023.

All 4 articles →

More by Corbin Crutchley

Discovering Odd Behavior with Angular Error HandlingChange Detection · Sep 28, 2023 Angular Internals: How Reactivity Works with Zone.jsSignals · Jan 2, 2023 Angular Templates — From Start to SourceState · Jan 20, 2021

← NewerConditional api urls in Angular with injection tokens Older →Angular Elements: Web Components with Standalone Components

React Hooks in Angular?! Share Lifecycle Methods Between Components in Angular

Vue

Vue

@Injectable serves as a substitute for an abstract class

Customizing constructor logic

The constructor isn't mandatory for Dependency Injection