
Build a Fullstack App with Next.js, v2 Routes & Route Groups
A second and third version of this course released using Next 13+, but this course is great if you want to see another example fullstack project. We now recommend you take the Build an AI-Powered Fullstack Next.js App, v3 course.
Transcript from the "Routes & Route Groups" Lesson
[00:00:00]
>> So now that we got our DV in order, what we wanna do now start working on the routes that we wanna create for the app. So for this app it's really not that many routes we only have about four, but like I said you can extend this app to be whatever you want and go crazy with it, it's fine what you want to do with it.
[00:00:22] But these four routes are definitely gonna challenge us, they all do some different things that have different constraints. So for us we're gonna need this slash register route which is sign up or any sign in which is exactly what it sounds like it's where we go sign in.
[00:00:36] We need the slash home route that's gonna be like when I showed you the project, the dashboard, that's the home for the dashboard, and then we're gonna need slash project slash ID. So if I click on a project I should be able to go there and see all the tasks for that one project.
[00:00:54] And that's what we're gonna cover in this course. Now we have an issue though. We have four routes and they have two completely different layouts, right? If we go back and look at the app, let me show you. So if we look at this layout right here for instance like the auth form, this register one, right?
[00:01:15] We have this layout here. But if we go to home, we have this layout. So I mean there are some simulators as far as this little glass thing and whatnot. But the layout as far as this navigation bar and stuff, it's completely different. So the slash home and the one first last project here, they have the same but the ones for the register and sign in have a completely different layout.
[00:01:45] And if you remember how next JS app directory works, we can put a layout on the route. So if we go into the app we can put a layout here, in fact there probably already is one cuz we scaffolded this out. So if we put something in here, it's gonna be on all four of those routes and we don't want that.
[00:02:01] So we have to figure out how do we maybe opt in to certain layouts or opt out of certain layouts. How do we how do we figure that out? Well, this is where route grouping comes in. So in intro, the next JSP 2, I talked a little bit about route grouping.
[00:02:16] This is where it actually is super beneficial. So what we're gonna do is we're going to basically group those routes as pairs so they can share their own layout and not be affected by the other routes. And it not at segments to our URL, right? We want our URLs to look like this.
[00:02:39] We want them to be clean. Because we could solve this just by saying, well, how about we put sign in and register underneath slash off? And how about we put home and project underneath slash dashboard? Okay, that might solve the problem but I don't wanna pollute our URL just because we can't separate layouts.
[00:02:58] I want the URL to be like this. But the complete different layout so we've got the group the routes. So what that means is we're gonna create a folder for auth with parentheses because when we tell next yes put parentheses around a folder we're saying, hey, do not add this segment to the route, I'm only grouping everything underneath it so they can share something common like a layout.
[00:03:18] So we're gonna put the register and the sign in inside the auth group, and they have their own layout. And then we're gonna put the home in the project inside the dashboard group, and they have their own layout. Does that make sense? So this is the use case where you can have more than one route layout and app directory.
[00:03:42] But you have to have at least one. So let's do that. So I'm actually just gonna get rid of pretty much all of this. I'll keep the head, the head one, but everything else is gonna go. Okay, so inside of here, typically we would put a layout on the route, but we're not cuz we're gonna have two routes in their own groups.
[00:04:07] So I'm gonna make one group here called auth. It should be a folder, not a file. With parentheses around it. So we got auth and we're gonna make another folder called dashboard. So this is new to next JS 13. And then inside of auth, we're gonna make a layout.
[00:04:34] That's where the layout goes for the auth. It's gonna be its own root layout there. And same thing goes for dashboard. It's also gonna have a layout. And then for auth it's gonna have another folder for register. And another sibling folder to that it's gonna be sign in.
[00:05:10] And because we're an app directory, you have to have a page if you actually want a page. Unlike the pages directory where you just give it whatever name you want and it'll make a route for you. We explicitly have to use the name page. So I go into the folder that I want to put a page there.
[00:05:27] So I put a page and register or put a page and sign in. And then in the dashboard, I'm gonna make a new folder for home, I'm gonna put a page in there Also in dashboard, I'm gonna make a new folder called project. And instead of putting a page in project, cuz I don't want you to be able to go to slash project and see something, I want you to go to project slash projectid, I'm gonna make a new folder in here with the square brackets of id cuz it's a dynamic parameter.
[00:06:07] And then inside of that folder I'm gonna put a page. So I have them all open here. So all the register with a page, all the sign in with a page, and then dashboard home with a page, dashboard project id with a page, and then layouts in both a dashboard.
[00:06:38] Any questions on why we organize it that way?
>> I may have missed it. But is there a reason for the prints around auth and dashboard?
>> Great question. The question was, is there a reason for the parentheses around dashboard and auth? Yes, there is. Next JS 13, when it sees these parentheses is gonna do something called route grouping.
[00:06:59] What this means is it's gonna allow us to group for instance the slash register and the slash sign in together so they share this common layout, but it's not gonna add off to the URL. It's not gonna add it as a segment. So if there were no provisions around this, in order to see the register page it would be your website slash off slash register and then you would see it.
[00:07:25] With these purlins it would just be your website slash register, it will ignore the auth. So it's just a way for you to get the same benefit of routes being grouped together without actually adding segments to the URL Cool, any other questions?
>> Folder or files with dynamic parameters?
[00:07:56]
>> Folders have dynamic parameters. You can't put dynamic parameters. You can't make a file that's a page that's not called page anymore. So you used to be able to use dynamic parameters because you can make a file whatever you want it in previous versions the next but in this version the next off pages have to be called page.
[00:08:22] So anything that's not page or a special thing like layout is probably a folder. It just looks weird in VS code cuz it the ID folder's the only folder inside a project. So it just put them on the same line like that. But that's a folder. This is a folder in a folder.
[00:08:40]
>> How does it know which route is the index route now after deleting the page.tsx?
>> I was wondering if someone's gonna ask that cuz it's gonna go to the page and like what you think is gonna happen if I go here? So to answer that question, we don't have an index route.
[00:08:55] There isn't one. And that's intentional because this app is meant to be an app behind a marketing website which would be the index route. This is assuming you got past that and here's the app. If you wanna go make a marketing website for you index route and add it here, do it.
[00:09:10] But this is an app behind that. So I didn't do it, but I forgot I didn't do it. [LAUGH] So I was like, wait, this thing's broke. But no, that's intentional. So there is no index route here and that's totally fine. But that's up to you how you wanna handle that.
[00:09:26] I think the way I would handle it though if I were to do it is I would probably make another, You know what? Yeah, I think-
>> You're saying you make Index dot tsx.
>> So you can't do that anymore unfortunately. You can't make an index dot tsx anymore in the app directory it has to be called page.
[00:09:47] So I mean the short answer is you just put page here, you just say page dot tsx, right. Boom, there it is. Well let me spell it right. That's the short answer. The problem is, The way that the route segments are right now you might have to start mounting them at different paths cuz what is this?
[00:10:06] Is this the index page to your app? Is this the index page to a marketing site? And then where are those other pages gonna go? So it's more about organizing them and not so much about whether or not you have it. So it's just a thought exercise on how you wanna organize them and what that URL structure looks like.
[00:10:22] So probably wanna sit down ahead of time and like map out your URLs and how you want them to be. But yeah, if you just wanna index route, you just put a page tx at the root of the app, and you'll get that. But you'll also have to now add a index route layout which we were trying to avoid cuz we don't want these to share layout.
[00:10:42] So that's another reason why I don't have an index route cuz I don't want them sharing a layout I want them to have their own layout and only way to do that is to have route grouping.
>> So if we just have the page at that, the base of the app directory, we need to have a layout?
[00:10:58]
>> I believe so. We can test that theory. Let's see. So if I say page, export, default, function, page. Why does it do that? My autocomplete is so strong. It's like you want that icon?
>> [LAUGH]
>> No I don't, I just wanna do div. just give me a div.
[00:11:30] My God, Jesus. Okay, so let's see. Yeah, you can see right there it literally breaks doesn't have a root layout you have to cuz it needs to be rendered into an HTML document and you didn't give it one. So that's why I don't have that there. Okay, any other questions?
[00:12:02]
>> If we were to have that there, is there a way to have that layout satisfied without the layout affecting the sub directories? So I saw in the RFC that they are working on the ability to where you can do something like this. How does it work? You can export something.
[00:12:23] My keyboard works, there we go. I don't know what it is exactly cuz I haven't seen the API for it. But they're working on the ability for you to export some type of hints here. It'll have some special name or something, and you can tell next.js I wanna opt out of this layout, or I wanna use this layout.
[00:12:40] I think they're trying to figure that out, but right now no, there isn't a way. But they're aware of it and they're trying to figure it out. So the way that I get around it is this. Yes.
>> I can see middleware redirecting to the slash sign in when the route is slash.
[00:13:04] Am I right?
>> You can 100% use middleware to redirect to anywhere based off of that, you can also just do or a hard coded redirect as well. You don't even need middleware to calculate it if you don't want to, you can as hard code that if that's what you wanna do.
[00:13:19] If you want this app to have an index, you can have it go there, but you're still just gonna run into the same problem. Soon as that index tries to load up it might throw an error. But if you did it on middleware which was at the edge it would avoid that entirely.
[00:13:34] So it really just depends on where you did the redirect. On the edge yeah that would have that would avoid it. So you could do it there if that's what you prefer.