Transcript from the "Type Aliases" Lesson
[00:00:00]
>> Interfaces and Type Aliases are a way you can give a friendly name to your types. Remember, we're still operating within a structural type system here. So the fact that you call your interface, car, or fruit or whatever it is, that's for you, and other people that contribute to your code base, it's just a friendly name.
[00:00:25] In many cases, you're going to be able to be free to choose whether you wish to use an interface, or a type alias. So we're first gonna talk about type aliases because they're the easier of the two concepts. Then we'll talk about interfaces. In particular, we're going to talk a little bit about how they work with classes and how they work with inheritance.
[00:00:48] We'll talk about what it means to say, interfaces are open in TypeScript. And then finally, I'm gonna give you a little guide about what are the cases where I do have an opinion about which one you use, and finally, defining recursive types. After this, we're gonna do our first collaborative exercise and build types that describe any valid JSON value.
[00:01:17] We're gonna write some code until the tests pass. So let's get to it. Type aliases. So, we've dealt with types that look like this, be they a piece of user information or a car. Colon and then a bunch of stuff. And you can imagine I'm sure you don't have to imagine too hard that as we add a third, fourth, fifth, sixth property to this, it starts to get very, very cumbersome.
[00:01:45] You're gonna end up making a spelling error or if you wanna add one more thing to this, maybe you have to update seven different places, it's just gonna become a lot, right? So, Type aliases help with this. Three things they do for us. They allow us to give our type a more meaningful name, something that is semantic, right, where the name of the thing describes its purpose.
[00:02:14] We're going to be able to declare a type alias in a single place and imported and exported it just as if it were a value the same way we would import an export functions or constants or anything like that from other JavaScript modules. So we can centrally define at once and refer to it in a bunch of different places, which is great.
[00:02:35] That's gonna make our lives much easier as things get more complicated. So, this is the first multifile example I'm showing you. Please just trust that imports and exports work reasonably well. So this is like a hypothetical filename. Here's an export from the file name. And then you can see it's imported down here.
[00:02:57] And the type information does sort of flow through. Here you can see that instead of just to saying I have this type and using this for every variable, every function parameter I care about, we're saying, I'm gonna create an alias for this type. So I'm gonna use this type keyword.
[00:03:17] I'm gonna give my alias a name. And then we're gonna set it equal to some type information. And it's important to understand a couple things here. One, this is a very rare situation where we can see type information appearing on the right hand side of an assignment operator.
[00:03:39] Usually it's all on the left. Almost always it's all on the left, right? The second thing this declaration we're making, this user contact info. This will disappear as part of your build process. It'll just compile straight out. So it doesn't add any asset size or anything like that.
[00:04:05] Alright, so this is how it's defined and we can export it just as if it were, function or something else. So let's look at how we can use it. So we import it. And then we can use it in place of explicitly stating the type itself. And we could use this in a bunch of different functions in this file.
[00:04:25] So we're really just giving a Type a name. That's all in it. That's why they call it a type alias. And you can use a type alias for any type you wish to define, there are really no limitations beyond what TypeScript itself can do. I'm just simply making the point here that we don't need things to be labelled with this specific type, we're just describing a structure here, right?
[00:04:50] User contact info, anything that has the right properties will make this happy. So here's an example of something that it does have this access property. We're storing it as a variable, so it's fine, but it's totally fine to use it even though the variable doesn't explicitly have user contact info as its type.
[00:05:10] All that matters is the structure lines up So, we already talked a bit about this declaration syntax. Type information on the right side of the equal sign. The convention is to use title case for names of type aliases and interfaces for that matter. And Just like variables, you can only have one type alias of a given name in a given scope.
[00:05:43] Seems weird for me to say that but that limitation does not exist for interfaces. So this would break for type aliases, but it would not break for interfaces. So we're gonna look at how a type alias can clean up some code that we've seen before. And in this case, we're back to our coin flip where we return an error sometimes, a success case in time.
[00:06:17] A success case if the coin lands the right way, we're gonna look at how this code can get cleaned up. And remember, this implementation is gonna be the same in both cases. So we're really gonna focus on this function signature. This is how we could clean it up with type aliases.
[00:06:38] So we could say here is the tuple for our error case. Here's the tupple for our success case, and then below here, we can define the third alias that describes the union type, right, the or between the two. By the way, this pipe here, this extra pipe, that's just auto code formatting, doing its thing.
[00:07:04] It is not harmful, but it does. It's also not necessary. Doesn't make things a little bit more readable because you can sort of just go, follow the line straight down. Look how much nicer this return type is compared to this whole thing. It's just a little bit more easy to read.
[00:07:29] All right, let's talk about, I'm calling it inheritance, it's pseudo inheritance, right? But how would we take an existing type alias and create something that sort of builds on top of it? So in this case, it's very similar to what we saw with when we were studying this and the intersection type.
[00:07:52] Special date has everything date has. Analytics effectively extends although we're not using an extends keyword, but we're accomplishing something equivalent, right? We're saying date is a type. And I'm gonna take everything that it's giving me. And on top of that, I'm doing some other stuff. So this is a good use case of this.
[00:08:13] This intersection type operator, not truly inheritance but has the exact same outcome.