Transcript from the "Type Alias" Lesson
[00:00:23] So if you think back to this syntax that we used for the object in our success tuple case, it gets noisy and complicated. If we use this all over the place, if we just look back at that function real quick, I actually made it look a little bit simpler here.
[00:00:40] But look at this return type, this is just a lot of noisy syntax. Imagine you have five or six functions that deal with this type, and you have this written in your code, like this. I just doubled the cognitive burden here by writing this type explicitly. And then imagine you have a whole library dealing with user info, and it's kind of all over the place.
[00:01:26] But there's only one place where it's defined. That is strictly not the case when we're doing this. It's almost like instead of defining a class, you have object literals with methods on the object. And you're using those all over the place, you have no central definition for those.
[00:01:42] It'd be very easy for them to sort of drift apart at different call sites. So we wanna have a central place where this is defined. And, of course, we want the benefits of import and export. I'm gonna open the equivalent code snippet in our editor here. So let's say that we have something that represents an amount, right?
[00:02:07] We've got a currency type and a value, so you could say like 300 Canadian dollars, something like that. And let's say we wanted to define a function called printAmount. Well, what we've done here is we've created a type alias. So we're saying typeAmount =, and then look at the right side of this.
[00:02:29] It's definitely a type, right? There are no commas here. This is a string, like string and number, these are types, they are not values. This is one of the only times you will see type information on the right side of an assignment. And this is something that will completely melt away as part of the compile process.
[00:02:50] This will get erased from your code, not your source code, but when you do your build, this will just completely disappear. Because we've defined this and we've given it a name, look at this, we can use it in place of what would have been a literal type like this.
[00:03:08] So instead of doing this, we can just say, that's amount. We could use this in a bunch of different places. You can, of course, export it, import it, as we'll see later. So here I've got an object I'm creating called donation, and it's valid. So there's no need that I say this is an amount, it must be an amount.
[00:03:29] It's literally just a shorthand for an explicitly defined type, there's no other formality to it. Is asking what are the differences between types of interfaces. I promise we will get to that, that is in this section, we will get there. So, a type alias, here's one difference with interfaces.
[00:03:55] A type alias can hold any type that you're able to define in TypeScript. So we could say, Something like that, MightBeNull, string might be null. You can put whatever you want here, that's not the case for interfaces, as we'll see later. But that is one of the great powers of a type alias.
[00:04:20] If it's a type, you can give it a name. And then you can import and export. So if we look at the example from last chapter where we're flipping a coin. And we've got this maybeGetUserInfo thing, and I've got in all its full glory, there's your return type.
[00:04:40] It's just a lot of syntax here, right? Lots of square brackets, lots of braces, it kind of makes you cross your eyes a little bit. So there's our flipCoin, it's heads or tails. And then maybeGetUserInfo, there's its return type. So if we were to model the return type as a type alias, We could do it like this, create a tuple type, right?
[00:05:16] UserInfoOutcomeError, UserInfoOutcomeSuccess. Then we could union those types together. And the tooltips get much nicer. You have words that can explain what the meaning of this thing is. It's a little bit like we're no longer telling someone how to build a watch, we're telling them what time it is.
[00:05:39] We're giving these types a semantic meaning, as opposed to just spitting out the contents of the structure that we're looking for. Just like variable names, right? Variables have a name, and you can write it in such a way that it conveys the purpose of this thing. Now you can do that for types as well.
[00:05:58] Just think of it like a variable for types. So let's talk a little bit how we can work with these type aliases. And I'm calling it inheritance for type aliases. It's not really inheritance, but it's sort of how do you build type aliases based on other type aliases.
[00:06:35] And sorry, to be clear, not all dates would have descriptions. We're creating a special date type for those that have descriptions. So we would say, all right, I want everything that's on the date type. And I also want to add a method to it, getDescription, which returns a string.
[00:06:54] And here we can actually create a SpecialDate, right? We're gonna create a new Date, and we're gonna add a method to it like this. And look at this, we've got newYearsEve, it's a SpecialDate, so the tooltip just got pretty clean. And here, look, I've got all of the Date functions, but there's getDescription, but getFullYear is still there as well.
[00:07:18] These are things that are available on a conventional Date. So if you wanna think about this kind of like inheritance, where we can say, all right, I have a type alias, I want to make another type alias that's a subtype of it. This is a subtype of a Date, it can pass as a Date.
[00:07:36] If you need me to give you a Date, and I hand you this, you'll be totally happy. It has getFullYear, it has valueOf, it can create an ISO 8601 string. But it's also got some other stuff. This is actually a more specific type of Date, cuz it has this extra requirement.
[00:07:56] The getDescription method must be on it.