This course has been updated! We now recommend you take the Introduction to Next.js 13+, v3 course.

Check out a free preview of the full Introduction to Next.js 13+, v2 course:
The "Typing Components & API Responses" Lesson is part of the full, Introduction to Next.js 13+, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Scott demonstrates implementing component types and API response types in Next.js.

Get Unlimited Access Now

Transcript from the "Typing Components & API Responses" Lesson

>> I know you've been avoiding typing your function parameters for most of the examples so far, but how hard would it be, or how hard is it in general to define types for everything in a next TypeScript code base?
>> It's not hard at all, I can walk through some examples of that, there's really only two examples.

[00:00:17] There's one for components and one for the APIs, so API is easy cuz you don't have to make them they're the same every time. For a component it will look something like we find it a good component. So I'll give you a good example would be a good example here.

[00:00:33] I don't know let's say you made a button I guess. All right, so, If you had a Button component here, which probably would be, I don't know why I did that, which probably would be a client component because it's a button and it's like clicking and stuff like that or maybe not, I don't know.

[00:00:53] You'll have to be the judge of that. So if you had a button here, you wanted to like make some props typically the way that I do it is I'll make an interface. So, interface button, and then you can put whatever props you want, whether it's one click, or not, on click something variance and, it's a string, or something like that.

[00:01:20] Whatever you want to put here and then I'll use in this case something called FC which stands for functional component. I'll bring that in that takes a generic which will be my interface called Button like that and now it's type checks. Now if I try to do structure here, you can see I have variants and it's ready to go.

[00:01:41] This is just freaking out because I'm not returning anything. Yeah, that's pretty much how I do it for the most cases is just make your interface, if there is a functional component, use functional component pass that in. And there you go, and then when you bring this into another component, if you hover over it in JSX, it'll tell you the props that you're missing.

[00:01:59] So that's one way to do it other people, what they'll do is, they won't do that instead they'll just do it here. They'll be like, Button, they'll do it that way, I think that gives you the same results but you're not telling React about it, I don't know what trade offs are.

[00:02:15] But I always do the other way. Because I think the functional component gives you access to all the other stuff that React gives you like children props and things like that, I think. So that's how I do it and then for the API stuff it's basically free. I mean you look at the example that's generated here it's always going to be next API requests and this one's always gonna be next response and then you're able to put a type here for the type of response you're gonna send back.

[00:02:42] But it's really not that necessary because there's nothing consuming this function that is going to have access to the return value of the response. Because like you're crossing the network barrier so it's not like there's a component over here that knows what this looks like. So there are libraries out there that are surfacing that allow you to have type safety between your back end and your front end without a build step in between but this ain't it.

[00:03:09] So it kind of doesn't really matter here, this is only for like composition I'm wrapping this function in a higher order function. So I need to know the return value is and things like that, unless about some component consuming this.
>> Signaling back to that one button component so that's not inside of the app directory, would you still need to put the use client at the very top to make this one specifically a client component?

>> Yeah, it doesn't matter where it is.
>> Okay.
>> It's eventually going to get important that app directory and you want it to be a client component, you got to put use client. Yeah, but right now, it's not ever gonna be used by the app anywhere because I never imported it anywhere.

[00:03:47] At the end of the day, if you think about it, everything has to be imported into a page at some point in order for it to show up on the screen. Because we can't just render a Button we can't render a component by itself. Doesn't matter how far that leaf is, it eventually has to attach to a branch.

[00:04:02] And that branch always leads to a page. So if you wanna put it on the screen, just like a regular React, if you have a component and it's not imported somewhere that's eventually part of the router, it's never gonna show up, it's never gonna get imported. So you can import it into lib and that lib can import in another lib but if that final lib isn't imported in a component somewhere that's impoted from a page it's never going to show up so that's how it works.