Use TypeScript Class instead of Interface or Type

Since TypeScript introduced Interfaces and Types, we’ve been getting lazy. It is so much easier to create an object that obeys an interface than it is to create a Class that obeys the same interface. But what have we lost in the process?

Checking Type at Runtime

In a typical application, if we want a strongly typed object, we create an interface or a type, define our object, and then assign an object to a variable with that type.

interface User {
  id: number;
  name: string;
}

const user: User = {
  id: 1,
  name: 'John Doe',
};

All goes well until we need to check to see if the object is of type User. To do that, we have to test to see if the object has the properties we expect and that those properties have the types we expect.

If we had created a class instead, we could have used the instanceof operator to check if the object is of type User.

class User {
  constructor(public id: number, public name: string) {}
}

const user = new User(1, 'John Doe');
const isUser = user instanceof User; // true

This is a much cleaner solution. We can also add methods to the class that operate on the properties of the class, which is not possible with an interface or type.

class User {
  constructor(public id: number, public name: string) {}

  // Silly example
  getName(): string {
    return this.name;
  }
}

But What About Flexibility?

But we’ve lost the flexibility of using an anonymous object to create the User. We can fix this by allowing the constructor to accept an object that has the same properties as the User class.

class User {
  id: number;
  name: string;

  constructor(user: User) {
    this.id = user.id;
    this.name = user.name;
  }
}

const user = new User({ id: '1', name: 'John' });

Dev Tools Impact

An additional reason for using a class instead of an interface or a type is that the type information not only sticks around so we can use instanceof checks. But it sticks around so we can see the class name in our debug tools. This becomes important when you are looking at a stack trace that happened during runtime that you do not have map files available for or when you are looking at flame charts or you are tracking down memory leaks.

When you use an interface or a type, the type information is erased at runtime. This means that if you have a stack trace that shows an object of type User, you will not be able to see the class name in the stack trace. This can make it difficult to track down bugs and performance issues.

Performance

And if you care about performance, there is one final reason you should want to use Classes instead of Interfaces or Types.

When you use an interface or type, it does not ensure that they fields stay in the same position as you copy it around.

What do I mean by this? And why do we care?

Let’s use the same object example we’ve been working with but using interfaces again.

interface User {
  id: number;
  name: string;
}

const user: User = {
  id: 1,
  name: 'John Doe',
};

const user2: User = { ...user, id: 2 };

We do this all the time, right? But what we’ve done is created one object, user, that looks like:

{
  id: 1,
  name: 'John Doe',
}

And another object, user2, that looks like:

{
  name: 'John Doe',
  id: 2,
}

That spread operator changed the order of our fields. Now, for applications that are small where we don’t care all that much about performance, this doesn’t matter. But, under the hood, the V8 engine is going to create a separate hidden class for each of these objects even though they are essentially the same type. The more fields you have in an object, the more hidden classes you are likely to create. This eats up memory as well as causing the V8 engine to have to do more work to optimize the code.

One of the next optimizations I’ll be making in my code is to prefer Classes over Interfaces and Types. It is a trivial change to make and has huge benefits. I would encourage you to do the same.