Transcript from the "Typing an API Response" Lesson
>> We're gonna go do details that TSX. So, as is tradition, we go into deep details. And we modify this to details TSX. All right, now we get a bunch of type errors. It's exactly what we want. Before we get too far into details, we're gonna create a new file on the side here inside of the source directory.
[00:00:21] And we're just gonna call it API ResponsesTypes.ts. It's very common that you'll have a project, and you'll have like a grab bag of types that you want to do. And you put them in a separate file so you can import them in other files. People have varying different methodologies of doing this.
[00:00:44] I like just having Like one just for API responses, maybe one for other types of objects that I might have maybe common types of objects. Some people like to have one type one file that seems aggressive to me. But you know what you do you. I'm if you feel that's the best thing to do should do that.
[00:01:06] Okay, first thing we do is we gonna export a type of animal. This is gonna be kind of an enumerated type. So, our animals, we only have dog, cat, bird, reptile or rabbit. So if we identify something as an animal, it can only be one of literally only one of these strings, right?
[00:01:37] If we try and put horse in there, it's going to say nope, that's not an animal. I know that you told me that already. Yeah.
>> What happens if the API returned something you didn't expect?
>> Your Programme is gonna crash. So it does not help you with that.
[00:01:53] So when you tell it like this is an API response, and it's up this shape, right? The types are going to help you enforce that shape continues to look like that. But you're not saved from the fact that an API could change that on you, right? If you want something like that, you have to use something like what is it?
[00:02:10] TRPC or something like that or there are ways to generate types from API shapes, but I mean, that still can get messed up, right? So maybe a different way of saying this is that type script does not save you from that problem. You still have the normal problem of what if my API is broken?
[00:02:29] Yeah Yeah, I was at LinkedIn. I remember one of my companies, we actually generated types from API responses that ended up being more annoying than worth it to be totally frank with you. I would have preferred to just maintain the types by hand because the types of the generated were nuts.
[00:02:52] All right, export interface pet, and we're just gonna type what our pet looks like. ID is a number, name is a string. Animal is a animal. We just made that one. Description is a string, breed is a string. Images is an array of string. City is a string, and state is a string.
[00:03:33] Cool, cool. Export, interface of PetAPIResponse Some people like to really get into and say call this IPet instead of because it's an interface, right? And it's the kind of signifies to that, this is a type, that's a dotnet thing someone correct me if I'm wrong.
[00:03:59] I've worked at Microsoft at long enough to, I should have written dotnet I never did. I don't do it because it looks ugly to me, and usually it's not a problem. But I'll tell you that there are lots of people that do it that way. Number of results.
[00:04:20] Number start index, number end index, number has next is a boolean and pets is an array of pet objects. All right, so there you go. That is the types of our at least our pet API search result. And now we have this pet API response shape in a couple places in our code, and we just can continue to use it, which is nice.
[00:05:03] All right, so back at details.tsx here, we are going to import our type here, import PET API response from API responses types. Okay, the top of the render function here. If we don't have an ID here, because in theory this ID can come back as undefined, right? Like what happens if we end up on the details page, and they didn't give us a correct ID?
[00:05:36] Technically, it's possible for that to happen. And you can see here this ID can be either string or undefined. We have an error boundary. So let's just lean into that, right? If you remember down here at the bottom, there's an error boundary. Let's just throw an error, right?
[00:05:51] So if there's no ID then throw a new error. Why did you not give me an ID? I wanted an ID, I have no ID. I write great error messages, okay? This is a question, I suppose. Maybe a couple exclamation points. There we go, okay?