00:00 Alright. Let's talk about discriminated unions. We're going to make a type for API responses. And here, the AI is saying, hey. This can be a a series of objects with the the union, here.

00:12 So we're gonna have a status of loading, status success with data string, and a status of error is a string. Now you could definitely also do type loading state and success state and then union those together. I kinda go back and forth. It kinda depends on the way I'm feeling. And right now, I'm feeling like let's just do it all as as one one long, long thing.

00:33 I don't mind. Especially with Prettier, the formatter, auto formatting this, I feel like it's relatively readable anyway, so it's fine. So now let's make a function that, has a switch statement on the status. We've got our state. That's our API state.

00:49 So it's one of those, things. We're gonna check the status. That can either be loading success or error. And, that's the first cool thing about this is that, because each one of these has a status property, it, can union those together and say the status could be one of these three things because that property comes from one of these three things. The interesting thing about this too is if I comment this out and say, now the error state, I don't need a status.

01:16 We've got status on the other two. I don't need a status on this one. Well, that's gonna be a problem here because now it's saying, hey, one of the things that you're unioning doesn't have a status property, so we can't even check for it. It would be purposeless. There would be no reason to check for it because it doesn't even have a status property.

01:33 Now, you could, if you had to, you could say if, status in, state, then, you can, do that check. And now it's saying, hey, case error, that doesn't make any sense. So we'd get rid of that and then handle the error case by itself and be kind of a mess. So discriminated unions are are nice, and we're gonna keep that status right there. So in any case, once we end up in, this spot, we know that we're in a loading state, so we can return loading.

02:00 When we have our status as success, then we know that the state is a success state, and it will have a status of success and data that is an array of strings. So we can call, or or get the length of that array. And then for the error state, we know that the error is gonna be a string. So that works super nicely. Now one other interesting thing about this is it didn't have curly braces.

02:24 I like to have curly braces on all my states. So I'm gonna add those and we'll let the formatter fix that for me. And then it also doesn't have a break statement on any of these. And the reason for that is because we have a return statement right here. So the the reason this is ghost text is it says it's unreachable code detected, on that break statement.

02:43 So you don't need to have a break statement if you have a return statement because that's gonna exit the entire function. Not just the switch statement, but the whole thing. So we're gonna, not need to worry about these break statements. And then finally, you don't need a default case in here necessarily because, this is the state now is a never type, because you there's no possible other thing that it could be. It does not exist on type never.

03:12 State is type never because you could never get into this default case because we're handling all possible states or status values of the state. So we've gone through all three of these, and we know that the API state can't be anything else. Otherwise, we'll get a type error. Let me show you what I mean by that a little bit more clearly right here. So we'll save this.

03:36 We got all these loading states. If we console dot log, an unknown, state, then here we're going to say status unknown. Unknown is not assignable to any of the other, statuses, so we are not a valid we're not calling this in a valid way. So it's impossible for us to call it wrong. So therefore it's impossible for us to not have covered the default state.

03:58 So we don't need to cover or have a default state handler. Now, what if we did add another state handler here and we're gonna say status unknown? Okay. Well, now this doesn't have a problem, but we do have a problem because now we're returning undefined. We're not handling that case.

04:16 And so in that case, we need to add this, additional, state handling. And, sometimes in TypeScript with certain configurations, it will actually warn you of that. We have really loose configuration in this project, for the purposes of making it easy for you to get used to TypeScript. But in actual projects, you'll actually get a warning right right there saying, hey. You need to handle all the cases in, the switch statement, which is quite nice.

04:44 Okay. And that's the exhaustive checking stuff that we're talking about. Alright. So let's now create a discriminated union for payments. We've got a bunch of different payments.

04:54 In this case, I'm actually gonna make a credit card. We'll do payment. There we go. And that'll be our credit card. We got our bank transfer and PayPal.

05:05 Each one of these are gonna have different properties, but they're all going to share the type property. And so, this is an important thing that I wanted to make sure you all understood as well is that the property that you use for the discriminated union actually doesn't matter. You can call it anything you want. Up here, we called it status, and here below, we're calling it type. It doesn't matter what it is as long as they all have the same property, and they are all, I was about to say they're all of the same type, but they actually don't have to be.

05:38 But as long as they are all the same property name, then you can use that as a discriminated union. Alright. So let's make our describe payment, right here. And this is going to switch on the payment type, and we're gonna handle all of that. And this is just kind of review from what we did before.

05:57 So let's save that. And there we go. We've got our card ending in this, PayPal, and bank account. All looks just fine. If we were to try to add, payment type right here, we're going to get an error because payment doesn't exist on never.

06:13 You could keep the default in here if you want, but I would just remove it because it's impossible to call this with a type that, is incorrect. It's going to TypeScript is gonna throw an error. This is one of the things we love about TypeScript is, sometimes people get mad and they're saying TypeScript is always giving me red squigglies all over the place. And I like to think of TypeScript as the friend that you keep around because, they tell you that you have, something in your teeth even when you don't wanna hear it. But you do you do wanna hear it.

06:44 Like, you wanna get that thing out of your teeth. So, there we go. We've got our discriminated unions handling all the different types of, API responses and payment types that we have in here using, a discriminated union with the different, payment types. So there you go. Hopefully, that was fun and interesting to you.

07:06 Well done on that one.