However, there are some slight differences between the two and it's important we understand those. So interfaces are declared with the interface keyword, the name of the interface, and then this object where you define the properties and the type of the property. So interfaces always need to be an object type. And sometimes in some older code, you'll see them prefixed with this capital I, so IUser where the I means interface. It's not really something you see too much in modern TypeScript. Personally, I don't use it. The only reason I've used it here is so I don't get a naming clash.

Personally, I don't use it. The only reason I've used it here is so I don't get a naming clash. Actually, let's do this. It's not really used anymore, but you might see it sometimes. So that's why I wanted to just show that if you see an I prefix before a type somewhere, obviously, if it's in the type definition, it's obvious. But if you see it used somewhere like here inside the calling code, the I usually just means it's an interface. But again, I don't really see the need to do that. And type aliases are what this type keyword tells us.

But basically, interface will always expect a curly bracket after the name of the interface. You can't put an equal sign. You can't put a string. You can't put anything else after other than an object. So that is the first key difference is that interfaces can only be an object type. When you're trying to determine which one to use, I generally roll with the rule that standard data types are using interfaces. So interface where I can, if it's a data type, it's like a contract for an object or an API response or something.

So interface where I can, if it's a data type, it's like a contract for an object or an API response or something. I use an interface where it's an object and I use the type alias syntax for unions and intersection types. So we've already seen in one of our previous lessons where we covered the difference between literal types and enums. We use this union type here for defining the suit. So this has to be this has to use the type syntax. We can't use interface here because it doesn't make sense for this. Like we can't use an = sign.

We can't use interface here because it doesn't make sense for this. Like we can't use an = sign. It expects an object and it doesn't make sense for us to do this. So this has to be a type. So here's an example of an intersection. Let's say we have this interface of timestamps as a created a created_at an updated update. And then we define this persistedUser, which is the name of our type. It's the alias for the intersection of a User and timestamps. So User is using the interface up here, just has an id and a name. And timestamps is this interface defined right here.

timestamp. So User is using the face up here, just has an ID and a name. And timestamps is this interface defined right here. So a persisted User is the intersection of both. So we're basically combining those two together and we can see this here. We have ID, name, created, updated. If I get rid of a name, we'll get a type error. Property name is missing in type this, but required in type User. There we see another case where types are used for intersections. So there's some key differences between them as well. So interfaces are guaranteed to be named in your error message, whereas type aliases.

So there's some key differences between them as well. So interfaces are guaranteed to be named in your error message, whereas type aliases are not. So if we were to come out this name again and we look at this error message and we see this, we see this type User. So if we define an interface, we're always guaranteed to get the name of that interface in the error message. If we use a type nine times out of 10, we will get the name of the type alias, but every now and again, you will actually get this object type here instead. So that is something to keep in mind. It doesn't happen all the time, but it can definitely help, which is one of the reasons why I use interfaces when I can, because I'm guaranteed to get more helpful error messages.

It doesn't happen all the time, but it can definitely help, which is one of the reasons why I use interfaces when I can, because I'm guaranteed to get more helpful error messages. The next key difference is that interfaces cannot be used to rename primitives or literal types and type aliases cannot participate in declaration merging, but interfaces can. So what exactly do these two mean? Let's have a look. So renaming primitives, so we can basically alias any existing type to some other type name. So here we're just saying a type of customString is just equal to a string. So that means anywhere we use the string type, we could just use customString type. I could also do something like this, like alias User equals

So one isn't going to overwrite the other. They're going to merge together. Yeah, this is not something I've ever used or felt the need to use, but it exists for a reason. So we have to assume that there is a use case for this. So that's one thing to keep in mind. So if you get unexpected behavior in your type declarations, just check for a interface that's already been declared and check for type merging. So just to show this works, if I remove the ID, I'm going to get an error message here saying ID is missing in the type we've given it, but required in type merge User. And again, just to show that it's not just the first two properties.