React and TypeScript, v2

Fetching API Data

Steve Kinney

Steve Kinney

React and TypeScript, v2

Check out a free preview of the full React and TypeScript, v2 course

The "Fetching API Data" Lesson is part of the full, React and TypeScript, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve explains how to add types to state hooks when the data is returned from an API. A type or interface can provide the shape of the state. A default value, such as undefined, should also be provided to handle cases where the data is not loaded or unavailable.


Transcript from the "Fetching API Data" Lesson

>> So in the repository we're gonna grab this inspirational quotes, and we're gonna take it for a spin. Because the other thing turns out a lot of times in our UI apps, we always just don't have, we're not just making counters all the time, or even in memory, only to do lists.

Sometimes we have to talk to APIs. I know, I know, it happens, right? And we have to make network requests. Let's just talk about some of the pieces around that. And we'll also then talk about, what if we wanna pass set states through? And we'll kinda use that as a slightly more sophisticated playground for getting a few more concepts in there.

So go ahead and just pull that down, and you should be good to go. And I'll get set up as well. And then I'll see you in a minute. So there's not a lot to see in this app yet, because it is supposed to hit an API and I have not dealt with that yet.

So applications that are supposed to hit APIs and then don't, don't do a lot of stuff yet, but we will. I do have the functionality to hit said APIs, all right? We've got fetchRandomQuote and fetchQuotes. Just for those you that are interested, this is using a library called mirage.js, which simulates an API server.

So I don't have to worry about core stuff later, but it's also really great for testing. Or the hypothetical situation where you need to build a UI before the API is ready. That happens to me.
>> That's why we use Frontend Masters-
>> Yeah.
>> For development, then the backend can just make it real.

>> So right now we have a problem, which is, theoretically, we don't know what a quote is yet, right? And that's an easy fix, but this is where I let TypeScript handle everything for you. It's really good about that, until it does not have enough information. That's usually the only time that you need to step in because you're like, yo, useState is like, quote.

Quote is undefined, right? And it thinks that it will forever be undefined. It's like, cool, quote is undefined, you can only set quote to undefined, now great. And then, I think, if I tried to use quote down here it's like, we do catch it. It is a constant of undefined, you almost always get the loading situation here.

So, what we need to do is figure out, if we tried to take the solution that we had before, if I look at the quote type, I can see it has an id content and a source. Really, I need the content and the source to make this work.

And so, one solution, and honestly depending on your use case, which is not a terrible solution, which would be to give it what I call an empty value in this case. And then maybe you have a skeleton loader, and you get the right shape of everything. If you can pull it off with whatever you're working on, this does have some problems, which is now like, this won't work because technically this is an object that exists.

Also it's like, this is not prepared to have an ID because it's trying to guess it from the type. There's lots of other edge cases. Let's talk about the more generic one where it's like, the data might have one of a few different shapes, or more than you have, more than you can just fake out in the very beginning, or to the point where it's not worth it.

So in this case, we basically just need to say kinda like when we used a question mark before to say, this is either this value or it's undefined. We've seen this syntax, and if you've used TypeScript before you've definitely seen it, but I made promises that if you hadn't used it you should be able to join with us.

And we can say, basically, pass it a generic or a type argument to what this should be. It is trying to guess, but in the event that it cannot guess correctly, cuz it does not have enough information, we can basically say, okay, this is a quote, or it's undefined.

Right, so now it has figured it all out for us, right? We just had to give it a little bit of a helping hand to get it all the way there. And this will theoretically work for us in this case. So now this one will fetch a quote when it finally runs.

And you'll notice that if I took this out, because it's commented out, and the JavaScript will still run if you don't have a compile error. So it's why you saw just an empty screen, if you just spun up the app and the loading indicator didn't stay there forever.

Cuz the JavaScript was running, it was just a TypeScript issue that we had at that point. But now it knows that it can be one or the other. We can actually pull this in. What's really cool about this, that I kinda wanna point out in this situation, which is up here, quote is quote or undefined, right?

Let's just, I don't know, console.log a quote in the market remind me to take it out. It's quote or undefined, right? Here we're saying, it's quote or undefined. But if there's no quote, return. And not only does TypeScript check the actual types in the type system, but it's also kind of analyzing your code, right?

And this is a dead end. In the event that a quote is undefined, right? It's faulty, we return. That means this code path stops here, right? This branch timeline ends, right? It's been what pruned? Is that the term of art? Note, at this point forward, if quote exists, at all, it can't be undefined anymore, right?

So you'd no longer have to deal with the fact that it could be a quote or it could be undefined, because the world in which it was undefined ended on line 29, right? And you can just kinda move along and it's like it has already analyzed your code, it has figured it out for you.

So it's one of those things if you find yourself doing all these extra checks, you could hover over it. If I see somebody had put an like quote nn to make sure it exists, right? I can hover over and see was this code necessary, right? And get a sense of, is this actually quote or undefined, or is it now definitely a quote cuz I've done something, right?

To confirm it one way or the other. And this will come back to surprise us in a delightful way, unlike most technical surprises, which are not delightful, when we work on action creators and reducers later. But, yeah, that is a nice thing to know as you kinda go through and work through all these things.

But if you don't have a default value, you can say, could be this thing or undefined. You have lots of options, you just have to help TypeScript along the way. And sometimes, in return, TypeScript will help you, right? It's a symbiotic relationship.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now