Type โœ” Vs Interface โŒ: Why you should chose type over interface in typescript.

Sheraz ManzoorSheraz Manzoor
4 min read

I have come to a solution that you should always use types over interfaces. Let's breakdown why!!

  • Interfaces can only specify objects, but type alias can specify objects and everything else. Let's say we have a single Address field and with type you'll define its type like this:
type Address = string;
const address: Address = '123 Hallway'

But you can't do such stuff with interface like:

interface Address = string; //error
const address: Address = '123 Hallway'

Because interface alias can only define objects. We'll need to change structure altogether if we want to use interface like:

interface Address {
    address: string;
}
const address: Address = {
    address: '12 3 Hallway'
}

That's first problem with interfaces.

  • type alias can define Union types and interface alias can't: Let's user can have multiple or a single address:
type Address = string | string[] ;
const address: Address = '123 Hallway'
const newAddress: Address= ['123 Hallway', 'Flag Plaza']

string | string[] is called a Union type, address can a string, or an array of string.

You can do such stuff with interface alias.

  • types alias can easily use utility types. Interface can do but it will look ugly, for example consider a User Object:
type User = {
    name: string;
    age: number;
    created_at: Date;
}

Now, let's say we have a guest Object, that is not logged in but we can check when it was created (first landed on the page). In this scenario, guest is like a user but not an actual user. We want to have created_at property in Guest from User In type alias we do it like:

     type Guest = Omit<User, 'name' | 'age'>

Technically it is possible with interface but see how it works:

type Guest extends Omit<User, 'name' | 'age'> {}

It works but it is an ugly syntax, isn't it?

  • Sometimes you will need to describe tuples. Here is how we describe it with type alias
type Address = [string, number, string] ;
const address: Address = ['Hallway', 2, 'Abdul Plaza']

But with interface, see how we do it:

type Address extends Array<number | string> {
   0: string
   1: number;
   2: string;
}

const address: Address = ['Hallway', 2, 'Abdul Plaza']

Ugly syntax again.

  • With types alias we can extract types very easily.
const love_bonito ={
    level: 1,
    store_id: 'scad_12hdedhefgfeaa',
    country: ['US','PK','IND'],
    user: {
        user_id: "blah',
        username: 'nishat',
        likes: 421,
    },
};

// let's extract type for love_bonito
type LoveBonito = typeOf love_bonito;

// or even something inside love_bonito
type User = typeOf love_bonito.user;

Bonus for this is that if we already now level is always one and nothing else, we can do that as well:

const love_bonito ={
    level: 1,
    store_id: 'scad_12hdedhefgfeaa',
    country: ['US','PK','IND'],
    user: {
        user_id: "blah';
        username: 'nishat';
        likes: 421;
    },
} as const

// let's extract type for love_bonito
type LoveBonito = typeOf love_bonito

// or even something inside love_bonito
type User = typeOf love_bonito.user

Now level will be inferred as 1, not as any number.

  • With interface alias you can redeclare an interface,
interface Home {
    rooms: number;
    light_bulbs: 12;
    rented_to: "Abu Turab";
}

interface Home {
   fans: 16;
}

// final type 

interface Home {
    rooms: 3;
    light_bulbs: 12;
    rented_to: "Abu Turab";
    fans: 16;
}

We can't redeclare type alias. You might thing, "Oh! Sheraz, here, this is a plus point of interface", but actually its not!!!

It sounds confusing, to have multiple declarations with the same identifier throughout your codebase. It seems really confusing to me.

Suppose you are working with a team, you knew about type of an object (types declared with interface), but somebody in your team redeclares and changes it, what would you do.

But with type alias this problem is sorted out as well. If you redeclare a type it throws an error duplicate identifier

  • The name of library is TYPESCRIPT not INTERFACESCRIPT. That might be funky but yeah, why would a company chose to name their library TYPESCRIPT and not IBTERFACESCRIPT. If company is preferring type over interface, so why don't you? ๐Ÿ˜†

Conclusion

Always prefer types over interfaces. Some devs say that interfaces load faster than types... But that happened in past. Now a days there's no difference regarding performance. There are some use cases where you might need interfaces, but it does not mean that you should interfaces all the time.

0
Subscribe to my newsletter

Read articles from Sheraz Manzoor directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Sheraz Manzoor
Sheraz Manzoor

I am an experienced Frontend Developer currently working at Infinity Devs as a MERN Stack Developer. With a deep passion for creating intuitive and dynamic web applications, I specialize in technologies like React, Next.js, Typescript, zod, SaaS and Tailwind CSS. I pride myself on delivering clean, efficient, and responsive designs that not only meet but exceed client expectations. In my career, I have worked on everything from tiny websites for small businesses to complete custom web applications. With such a strong understanding of client needs, I utilize my own technical capabilities to create new solutions. By making my user experiences better or performance faster Key Skills: -Frontend Technologies: React, Next.js, HTML, CSS, JavaScript, Tailwind CSS -Version Control: Git, GitHub -Responsive Design: Mobile-first development, cross-browser compatibility -Collaboration: Excellent communication skills, experience in agile environments Professional Approach: -Shared Ownership: I believe in collaborative effort and shared responsibility to ensure the success of every project. -Rapid Execution: Efficiently managing time and resources to deliver quality work promptly -Show and Tell: Regular updates and transparency with clients to ensure alignment and satisfaction -Bias for Action: Prioritizing proactive measures to tackle challenges head-on -Systematic Approach: Methodical planning and execution to maintain high standards -Design Thinking: Emphasizing empathy and creativity to solve complex problems and deliver user-centric solutions Interests: When Iโ€™m not coding, you can find me exploring the latest in tech, reading about advancements in AI, or enjoying a good book. I also have a keen interest in photography and love capturing moments in nature.