2023-06-28
2258
#typescript
Yan Sun
19174
105
Jun 28, 2023 â‹… 8 min read

Types vs. interfaces in TypeScript

Yan Sun I am a full-stack developer. Love coding, learning, and writing.

Recent posts:

React Native Push Notifications A Complete How To Guide

React Native push notifications: A complete how-to guide

Learn all about how to implement push notifications in React Native in this ultimate guide and step-by-step tutorial.

Fortune Ikechi
Jan 17, 2024 â‹… 12 min read
Exploring Effect A Meta State Rxjs Like Framework For Writing Typescript

Exploring Effect, a meta-state RxJS-like framework

The Effect library helps you better handle async code, types in async scenarios, and errors in TypeScript projects. Let’s see how.

Isaac Okoro
Jan 17, 2024 â‹… 6 min read
Exploring The Redux Second Generation

Exploring Redux Toolkit 2.0 and the Redux second generation

Catch up on the new wave of Redux updates to Redux Toolkit, Redux core, React Redux, and more in the Redux environment.

Stephan Miller
Jan 16, 2024 â‹… 7 min read
Next.js No-Code Platforms Rapid Development

Exploring Next.js no-code platforms for rapid development

We explore the advantages, drawbacks, and best practices associated with using Next.js no-code platforms to speed up frontend development.

Oyinkansola Awosan
Jan 15, 2024 â‹… 6 min read
View all posts

11 Replies to "Types vs. interfaces in TypeScript"

  1. To me type aliases are more strict, so it makes more sense for me to use that by default – even for objects. The only time I use interfaces is to expose types publicly so that the consumer of your code can extend the types if needed, or when implementing with a class.

  2. In your example of that interface with tupe [string, number] is actually an interface that has one of its members defined as a type (of a tuple) so no confusion here.
    One difference that you didn’t mention is when object implementing some interface can have more properties than the interface defines, but types limit the shape to exactly what type has defined.

  3. “Interfaces are better when you need to define a new object or method of an object. For example, in React applications, when you need to define the props that a specific component is going to receive, it’s ideal to use interface over types”

    There is no argumentation here. “object or method of an object”, while being vague, has nothing to do with a functional React component which is a function.

    You’re just making more confusion.

  4. There are so many errors in this!

    1. “In TypeScript, we can easily extend and implement interfaces. This is not possible with types though.”
    What? Classes can implement types. Types can “extend” types using ‘&’.

    2. “We cannot create an interface combining two types, because it doesn’t work:”
    Again, what? If A and B are interfaces, you can create an interface C like this:

    interface C extends A, B {

    }

    This is a very misleading post.

  5. I, personally, tend towards `type` when defining Prop types.

    The things you get with `interface` (namely `implements`, and the ability to extend through redeclaration) aren’t really useful in the context of Prop definitions, but the things you get with `type` are (namely unions, intersections, and aliases specifically).

    They’re mostly the same in this context, but occasionally you’ll end-up NEEDING to use type so you define PropsWithChildren using the react library type React.PropsWithChildren and since I prefer consistency, I’ll just use type for all PropTypes.

  6. You say, “Interfaces are better when you need to define a new object or method of an object.”, and then straight away in the next box you use a type to define an object.
    “`
    type Person = {
    name: string,
    age: number
    };
    “`
    So which one is it? The article doesn’t seem to adhere to its own advice which is confusing.

  7. Great stuff man, thanks a lot
    Differences between types aliases and interfaces are not easy to understand, and sometimes we don’t know which one to use, that helped me to figure it out better

Leave a Reply