00:00 Alright. Let's jump into this. So we wanna add an explicit return type annotation to these async functions for fetching a user. So I'm gonna add promise user. So this function is gonna return a promise.

00:11 And interestingly, anytime you have an async on here, your return type, if you specify it, always has to be a promise. Async is always gonna be a promise. And so whether it's inferred or you explicitly type it, it's always gonna be a promise. Just keep that in mind. If you ever are, like, calling a function and then you go to that function, you add async to it, you're gonna have to go back to wherever you're calling it and handle that promise.

00:37 It's yeah. That's just the way that it is. So here we've got, this is explicitly going to, return a user. You'll notice here we are using the promise generic for that user. If you don't, then it actually works out anyway because we are being, we're being explicit about what is being returned and this happens to match user.

01:01 If I, take off Alice, then we're saying, hey, hey, that resolve is supposed to resolve to a user. You'd have the same thing, here if we didn't have a return value because we're saying, hey. This promise has got to return a a user, then we've got to make sure that this resolve is being called with that user. So, anyway, let's get that back to the state we want. There we go.

01:24 And then we can come down here. You could, also add a explicit return to this as well, and then you could remove that one. Whatever however you want it to be. But if you, go through this, then you'll see user is, correctly typed as a user. Products is gonna be correctly typed as an array of products.

01:44 We can console log these if we want and load the data and ta da. There it is. So, the goal here was just to have you explore return value versus using the promise generic. Hopefully, that was interesting and fun, and now you know how to handle all of that. The one other thing I should mention actually is you might think, well, how do I type the reject?

02:06 What if I need to, say yeah. Here. We'll do math random. There we go. Resolve reject.

02:12 Awesome. Well, the thing is you can't actually type the reject. So we could say, user and you might think, okay. Well, error. Yeah.

02:20 Sure. But that is not allowed. The promise generic only supports one argument and the reason for that is that it's actually impossible to type an error. Errors can happen for all sorts of reasons and you really just don't know. So if we were to handle a, catch error right here, then let's take a look at the type of the error.

02:41 And here it is typed as any. I'm gonna guess that it actually is for, historical reasons. I would want to type this as unknown. And the reason for that is because you want to verify that this is what it says it is. If you don't remember any versus unknown, go back to that workshop where we talk about that.

03:00 It's an important concept. All my errors, you want those to be typed as unknown. So that you handle them properly. Because you really just don't ever know what what type is this error because errors can be thrown for any number of reasons and even if we're explicitly rejecting right here and we know, oh, this is gonna be an error. It could You can actually throw or reject just a string or you could, throw, throw yeah.

03:28 Throw a string this way too. You like you can do all kinds of things. Errors or errors be flying. And so, yeah, you don't want to or you cannot type an error in any context, at least, from the, like, print the platform APIs. You could make your own utilities and explicitly, return, like, here's the here's the value and here's the error if there was an error like and you could type those if you want to.

03:55 But as far as try catch is concerned, yeah, you can't type those. Alright. Good job on this one.