I wanted to pause for a moment and talk about non component type scripts. So we're not always going to be using touch script in the context of say, a view component or react component. Sometimes we're just writing types scripts. It looks like JavaScript, it's enhanced with types and two common scenarios I just wanted to touch on that we may run into as Laravel developers are making requests

that we may run into as Laravel developers are making requests with something like Axios and Fetch. And I wanted to show you how to make that more type saved and more user friendly. So let's take a look. Uh, we have a vanilla Ts, so it's just a regular ts file. Uh, we have a song that we have defined here as a type and it's got an ID number title string created at string.

Uh, we have a song that we have defined here as a type and it's got an ID number title string created at string. And we are posting songs. We're creating a song and this is the payload and here's the response. So the response is anything if I come in here, I can get the Axio stuff, but I don't have any information about the response. But Axios does, uh, provide a generic, so you can say this is going to return a song.

But Axios does, uh, provide a generic, so you can say this is going to return a song. You can specify that, right? And so here you can already see the Axios response is song, right? So now we get response data and now we get some nice auto complete and type safety around that just by providing that little generic that Axios has already given to you. Beyond that, if you want

that little generic that Axios has already given to you. Beyond that, if you want to tap into something like a config, right? So you can see that Axios config is a type that is available to us. So if we wanted to say constant config is of type axios config and import that from Axios, well now in creating that config, we get a lot more auto-complete. We know what is possible in here, right?

that config, we get a lot more auto-complete. We know what is possible in here, right? So we know what base U RL should be. It should be either a string or undefined. We know that adapter should be either an axios adapter, config, whatever that is an array of those adapter configs or undefined. So we don't have to go to the docs. We can kind of figure it out as we go what exactly these things mean based on the types

We can kind of figure it out as we go what exactly these things mean based on the types alone, which is pretty cool. Okay, next up, what if we are just using fetch? Well, fetch out of the box doesn't really have a lot of great support for Typescripts, to be honest. Like you can't really specify much about what you're doing here. Um, we're, we're fetching a list of songs. We're getting the JSON results

Um, we're, we're fetching a list of songs. We're getting the JSON results and then we're just getting anything we don't actually know. So in cases like this, you can sort of force Typescripts to understand what the result is and basically just tell it, Hey, it's gonna look like this. And you can do that by saying As, and then you can say Promise, which is a built-in type script utility. And you'll say the promise is going to resolve

which is a built-in type script utility. And you'll say the promise is going to resolve as a song, right? So now we get song, which is pretty cool. So song and now we have all of the stuff we're actually looking for. Now, when you do this, keep in mind that you are telling TypeScript this is what's happening. It's on you to be certain that that is what is happening. If it results in something else,

It's on you to be certain that that is what is happening. If it results in something else, TypeScript will no longer catch this error. You are saying this is going to be Promise song, pinky Promise. I would probably wrap it in a very, very light function. Something like fetch it, although that's a silly name, uh, where you can provide a generic and make this a lot more flexible, right?

where you can provide a generic and make this a lot more flexible, right? So you provide the URL, you provide any options, you do the fetch, you throw an error if something went sideways, and then you still do that as, but really it just becomes a lot more flexible so that you can just use this over and over again and specify the generic that it returns and just make it a little more concise. So if you have response for each,

and just make it a little more concise. So if you have response for each, 'cause we're getting, we're getting the array of songs back, right? And then we have song and now it should be yep, created at ID title. So you just get, still get that type safety. It's a little more concise and a little more flexible. So those are two things that I would imagine as a layer of all developer you are probably going to reach for

So those are two things that I would imagine as a layer of all developer you are probably going to reach for or use somewhere in your TypeScript application. So I wanted to give you just a little primer on that before moving on.