Okay, so I need extras. What does it look like? Well, it shows up here and here. So apparently it's an array, but what kind of array? You kind of have to go and hunt through that definition to figure out what you should be using. It turns out there is a little generic, which you can add, which is pretty simple to use. And it's in this ebook, effectivetypescript.com, it's from Dan van de Kamb, and he was actually a speaker at the conference talking about using TypeScript types and databases and how to deal with that. Pretty interesting session, highly recommend it.
And using that resolve function, we can make stuff a lot more readable and I'm not actually gonna go to that post because you kind of have to hunt through it. I'm just gonna take it from my own code. Let's see. So it's opened up on my other screen. Let's see if I did things right. I copied it, yep. So I've got the resolve type here and basically it says, well, loop through all the properties in the type, just like we did with the deeper read only. But in this case, we're not even gonna do anything with it. We're just gonna echo out that same property. So the same type and everything. The only exception is if the type extends function, then we're just gonna return that function itself, the original type. We're not gonna do any mapping with it. In this case, we wouldn't even need it, but that makes it a bit more generic. So if I take this resolve and now say, I wanna resolve this whole thing, this whole type. So all I've done is wrapped the whole pick and type union inside of resolve. If I now look at items ordered, it's very readable. I can see there is a name, price and extras, and I can see how clearly what types are there. And I can even see, okay, the name and the price are read only, but the extras are not read only. So that was completely not clear before. So I might wanna say, well, I wanna define that as read only as well. So now all of them are read only. And the same, if I go back here, I hope for over that same items order, it resolves exactly the same way. So it's a small thing. And it's kind of like, I wish that was part of the standard TypeScript definitions and TypeScript would just do this because it makes types much easier to read instead of showing how a type was constructed, it shows how a type is actually, how it ends up, I should say. So much, much easier.
So, please add that, just, well, it's simple enough to type in, but you can copy it from the source if you want to, and make sure that that item order looks exactly like this with the read-only. So I'm gonna open up the breakout rooms. This is also gonna be the last thing we do. The last thing we do, it's almost 7 o'clock, at least 7 o'clock my time. So we've just got eight minutes left. There are a couple of more things in the slide deck and the exercises, which are interesting, but we won't have time to do it. I'll very briefly talk about it after this exercise. When that's done, we're gonna conclude and wrap things up. So see you all in four minutes after making this change and seeing the effects on the type mapping results.
So that's everyone back. So let's wrap things up cause we're out of time. I did have a few exercises left. So I'm briefly gonna, very briefly, gonna tell you about it. Opaque types are really nice. Turns out there's another book in the application because account and amount are switched. They're both numbers so TypeScript thinks, well number to number parameter is perfectly fine. And it doesn't realize that their type of number or the intent, the business intent with the number is completely different. So with opaque types, and that's a type like this, you can actually create this type which derives this place from number but adds some key to it. And so the amount, we add the key amount which account we add to key account. Then we've got types which are actually different but will still also work as a number. So we can do something like this. Change the function definition from amount and account from numbers to amount and accounts because in the actual call to the checkout function these two are flipped. And in that case, if you type those as well TypeScript is gonna warn you saying well, you can't assign an account to an amount and the other way around. So, you use costs here. Now, costs are nice but they kind of, well, work at compile time but only compile time. So, a slightly better way is to start using type predicates functions. And a type predicate function looks like this. So, the function is account which takes some value. And the important part is this, the result value is account. So, if this returns true, then whatever was passed in is considered to be of type account. And if it's false then it's not considered to be of type account. So, you can do whatever you want. I'm checking the type. So, is type a number and is the length of the number 10 characters then it's considered an account number, otherwise it isn't. And with that, you can do something like this. So, at runtime, you can check whether it's an account. This will be used both at compile time so, if what the type passed into account is a number then it's at runtime gonna say, well, okay, then it could match that check. So in here, sorry, at the compile time, it's gonna say, well, if it passes that check then here account's amount. No, sorry, account must be the right type and otherwise we can throw an error.
Comments