Hey there, my gorgeous friends on the internet. In today's episode, I'm going to throw you some TypeScript examples that might have your head scratching a little bit. So we're going to talk about compiling and runtime and how TypeScript behaves. And yeah, let's have a look, shall we? Wow. It's like infinity. We're all connected. Welcome to the show. Pour yourself a coffee script and let's get going. So here's a wee example of a TypeScript code example that might make your head scratch a little bit. So let's say we're making a game of some sort. And let's see if we're encountering a stranger, a mystery man, if you want to say, an mystery man can be either an enemy or it can be a friendly. So let's make two interfaces. I'll make an interface and I'll call this NPC. So every person, whether it's a friendly or enemy, should have a health bar. So I'll say health. And a health is a number. So we can pass down like a 10 or a 20. Cool. So we got that going, which is nice. And then we'll make a separate interface for an enemy. Now, regardless if it's an enemy, it should still have health, right? So we can use the extends keyword here and say NPC like that. So now every enemy is going to extend the NPC, meaning it'll have health and everything else that we add here. So let's say it has a power or a weapon. I don't know. Still a number. We'll pass that down as well. And finally, down here, I can say that we have a type of stranger that can be either enemy or an NPC. All right. So I hope that's nice and clear. Cool. So now down here, let's say I want to make an enemy. So make enemy. So here, let's see, we're encountering a stranger. And a stranger is a type of stranger, either enemy or NPC. Cool. Now you might be tempted down here to do something like this. Stranger is an instance of enemy. So if I know it's an enemy, then I can return both properties here, power and health, right? Return power. Let's do health. And I can do stranger.health. See, that works. And then I can do power stranger.-- oh, where's power? And why is this red squiggly line here? So that doesn't work if I do power down here. However, at the bottom, if I do something like const test equals to make enemy, and I can pass in health here, see, that's fine. And then power too. That's fine as well. So how come this code doesn't work? If we hover over enemy, it says that it only refers to a type, but it's being used as a value. And power here says that does not exist on type stranger. So it's just essentially how TypeScript works. TypeScript does all the type checking for you during compilation time. But at runtime, essentially all these types and interfaces all disappear. They all get stripped away, and you're just left with vanilla JavaScript in the end, because that's what the browser knows how to run. It doesn't know how to run this syntax here and this syntax here. So knowing that, now you know that this enemy here-- well, we're trying to get the value of it, but this doesn't really mean anything in this sense. So just remember that TypeScript is a superset of JavaScript in the end. Every JavaScript program is technically a TypeScript program as long as it doesn't have any syntax errors in it. So let's remove this. And what we can do rather is check if there is a property on that object. And if there is a property on that object, like power, well, then I know that must be a type enemy. So you can use the in keyword for that. So you can say power in stranger. So if there is a power property in stranger, then I know for sure that stranger is going to be an enemy. So now, as you can see, no more errors. And down here, stranger is a type of enemy. Another important note is that TypeScript operations will not affect runtime values at all. So let's say you want to put together like a function that returns you a number, but you can pass in a string as well. So let's make a compsion. Comp-- oh my god. Compsion was my mind on Jesus. Function as number, we'll call it. Cool? So OK, we can pass in the value. But the value can be either a number or a string like that. Cool. And you can also add number here at the end like that. And all this means is that the actual thing that you're returning, you're telling TypeScript, hey, that should be a number. Make sure it's a number. I'd be tempted to go down here and say return val return val as number. So you might go here and pass down like 5 and hit Save. And you're like, oh, it works the same way. Perfect. All fine. The thing though is this looks deceiving. If you say as number here, you're not actually running like an operation on this value and converting it or affecting it in any way. You're just telling TypeScript that you know better and that you know that the value that gets returned is for sure a number. However, again, if you really think about it, the way I told you is during runtime, all this TypeScript shenanigans goes away. So if we really look at this, it looks like this. So this would go away. All of this would go away. And all of this would go away. And what are we left with? It's just a generic function that can have any values in it again. So just look at it that way. So how can we fix this? Well, we can check the type of the value that we're getting in our function. And based on the type of, we can deduct what kind of type it is. So I'll just say return here. And I can just say type of like that, passing the value from the parameter. And then if this triple equals string, well, then we know it's a string. And then we can do whatever we want with it. I can maybe do a number, val, like that. Otherwise, just return the val because it's a number. And there we go. So now we don't have that anymore with the as. And that works fine. And if we try to pass in something else, of course, like if I try to pass in an object of maybe a number of 5, that's going to throw you an error. Now, again, this might not be as useful of an example because JavaScript is automatically going to convert that to a number for you. But you can imagine if you have a more complicated function, you can use this type of val to deduct what kind of type is actually getting passed in that parameter and then return accordingly to that. And last but not least, let's talk about how your runtime types might not be the same as the types that you have declared. So in this case, I have a dark vote here. And my declared type is just a value here that's a type of Boolean. So if the switch is on, then we go into dark mode. If the switch is off, we go into light mode. So cool. But what would happen if-- so this would work fine. If we do dark mode, I can pass down the Boolean. I can say true. But imagine we get this back from some sort of API response, this value here. So you could have something like response equals to await, fetch, and you're fetching maybe the data that tells you if it's dark mode or not. Like that, cool, right. And then you do result. And then you might be tempted to just set this result equal to an interface that you make up here. So you can say interface API response. Let's just do it like that for now. Whoops. Working with too many types. And I'll just do a mode here and say Boolean like that. So I can pass down API response like that. Cool. And then what we could do is say something like equals await. And then you can take that response.json. Blah, blah, blah. Like that. Cool, right. So in this case, even though you enforced that this API response should be a type of API response here with a mode of Boolean. But you might be wrong. You might not know. The API might be different. And you actually get back something like off a string of off rather than a Boolean of false. So again, this is one of those things that you want to avoid as much as you can in TypeScript. This is like one of the hardest bugs to decipher is when your declared types does not match the types that you get back from an API response. Who can get quite tough. So it depends what you're working with, whether it's React query or another library that does fetching requests. They're going to have a TypeScript section on how to actually properly implement it. But yeah, that's got to be it for me. Thank you so much for watching. Hope you enjoyed this episode. Let me know if you want more TypeScript stuff. I love it. I love it. I love it a lot. All right. Drop a sub, drop a like, and get out of here.
