When to use types (vs interface) in TS [duplicate]

Question

I cannot determine understand when, if ever, you'd want to use a type instead of an interface for a variable in typescript. Assume the following two:

type User = {
    id: string;
    name: string;
    type: string;
}

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

I can define a variable with both exactly the same was const user: User = .... However, here are all the things I can do with interface that I cannot do with types:

// Extension:
interface AdminUser extends User {
    permissions: string[];
    role: string;
}

// Using in abstract method:
abstract class Home {
    abstract login(user: User): void;
}

class AdminHome extends Home {
    login(user: AdminUser) {
        ...
    }
}

Just to name a few.

So my question is: when would you ever want to use a type?

Answer 1

EDIT (12/15/2020): At the bottom, I've added info on "types" in TS (or the equivalent idea in another language).

Unless I'm mistaken, you're not entirely clear what the purpose of an interface vs. a type is.

In OOP terms, interfaces do not have implementations. Types do. So an interface is basically useless unless a type implements it. Also, a type can only extend one other type. But it can implement many interfaces.

But what's that mean...

Say you have a Car, and a User. Very different types that you don't immediately think of as being the same in any practical way. Some may say, "well, you should create ICar, and IUser". But really, that's just not a practical way to think about interfaces. It would be confusing for User to implement ICar, and/or, ICar just seems to do the same thing as Car. What would be the difference to another programmer looking at the code?

Say you want them both to be (again just for the heck of it), "Self Describable", and you want them both to provide the info the same way. So you'd create:

ISelfDescribable {
   getSelfDescription ( );
}

Now, you'd do this:

Car implements ISelfDescribable {
   getSelfDescription ( return "I am a car!" );
}

User implements ISelfDescribable {
  getSelfDescription ( return ...some other completely different way of getting the info... );
}

An array of these objects would be (think about how else you would do this without interfaces):

Array<ISelfDescribable>

Now you (and any other dev looking at the code) knows for a fact, any object in this array, regardless of the concrete type, implements the "behavior" of ISelfDesribable. If you think about it, there is really no need to EVER know what a type is unless you're implementing it, you just care about the behavior. But you still need the type to implement that behavior.

Say one day you wanted both these objects to be "Insurable". They should both have a method, "setInsurancePolicy". You could create IInsurable { setInsurancePolicy ( policy : Policy ) }, and implement it in the types. Now you have objects that are both ISelfDescribable and IInsurable, and you can type an array of those objects as either one.

So for me, the big lightbulb went off when I got my head around that: types (and type hierarchies) should be concerned with concrete things. Interfaces should be concerned with behaviors that can be shared among different types. There's more to it, but that at least gives a notion of why you'd choose an interface, or a type. They represent different things in terms of programming, even if they otherwise appear the same.

(Addendum: Languages like Scala don't think in terms of interfaces this way. They do have a notion of "behaviors", but you can also implement behaviors, and override them. That may be too much academic blather for this particular question, but hey I need to kill all the monsters in the dungeon, not just the ones for the quest).

12/15/2020: TypeScript: Types vs. Interfaces.

Why use one or the other? Again, it relates to what you want it to represent and how exactly you want to use it.

A "type" is the "I need a contract but it's not a behavior definition like an interface" answer.

This allows you to semantically keep the differentiation. This is an interface, because it defines a horizontal behavior. This is a type, because it defines...a type.

Further along that line though, types are functional-friendly in a way that interfaces are not, because you can combine and intersect types. In React for instance, I've heard it said, "never use interfaces because they are nowhere near as composable as types."

So say you have two service calls, and you want to define a contract for the payloads. Interface? Nah...that's for horizontal behaviors. But a "type", yes...it types the payload but does not semantically define a behavior.

And, say you run into the common task of having to merge the definitions of two payload types into one (for a UI component or something). Using "type" definitions, the language makes that kind of union/intersection/etc straightforward.

So the logic still tracks; interfaces, horizontal behavior, types, vertical definitions that can be composed in a variety of ways.