if you're anything like me, you might see a video on next.js Project structure and think to yourself, boring next video. And I get that. It's not the most exciting thing in the world, and it's one of those things that I would rather be like developing features, learning how that works, and moving forward with that. But if you're wanting to build professional next.js applications, I think that it is important to consider how you are structuring different folders and files within your overall application. So, that's what this video is going to cover. I'm not going to like mess around it, drag this video on super long, but I'm going to show you some different things within xjs that you can use for your project structure, and maybe some different strategies that you can use that kind of makes sense to me. So, here in redox, you can see right here that next.js is unopinionated about how you kind of organize, and they say co-locate project files. I think they're being a little bit fancy here where you put your

project files is probably what I would have said, but they give you some kind of different things to consider when organizing your next project. So they say safe co-location by default, and my interpretation of this is co-location is effectively if you have a certain page, say you have a dashboard page, well you could create all of your components that you use for that dashboard page all within your kind of dashboard folder. So your all of your code that you use for your dashboard is right there within that dashboard folder. It's all kind of co-located together, so you have safe co-location by default. And what they mean by this is that while each folder in Next.js, it can potentially represent something. So if you have a dashboard folder and you create a page.js file within that folder, you are creating a public route for your forward slash dashboard. And similar when you create a route.js file within your dashboard folder, you're creating a publicly accessible route. However, you can create folders that don't contain a page.js or route.js file, and those aren't going to be publicly

accessible meaning you can still use those folders to co-locate different components or different application code without necessarily needing to worry about those being publicly accessible. And that's what it says here: even though route structure is defined to folders, a route is not publicly accessible until page.js or route.js file is added to a new route segment. So here they create a dashboard folder, a settings folder, an API folder, but they never add a page.js or route.js file to these folders, so they don't make these actually publicly accessible. And they go on to say, even when a route is made publicly accessible, only the content returned by h.js or route.js is sent to your client, which is a nice feature of next.js. And what this means is that project files can be safely co-located inside route segments in the app directory without accidentally being routable. So like you wouldn't want to create a components folder and actually create a route in your application called forward slash components. For most apps, that probably wouldn't make a ton of sense.

here they show an example of they create a components folder, and they have a button.js file within this components folder. But that's not routable because they are actually creating a page.js file or a route.js file within their components folder. Now, within their dashboard folder, they create page.js. So that does create a route at forward slash dashboard, but they create a nav.js file within their dashboard folder. But that's not routable because it's for one not a folder with a page.js or raw.js file. Only the code returned from the page.js file is sent to your client. So if you wanted to use like some navigation page or a navigation sidebar, and it was just for your dashboard, and you wanted to co-locate that within your dashboard folder, well, you're fine to create a nav.js within your dashboard folder. That's not going to be sent to the to the client. Only the code returned by your page.js is going to be sent to the client. So you're not going to accidentally create a you know dashboard.

forward slash nav to do that. But if you did want to do that, then you would just create a nav folder within your dashboard folder with a page.js file. And they do a similar thing within the API folder. They create a route.js file within the API folder, which is publicly routable because it's a route.js file. But they also created db.js file within the API folder, but that is not routable because it's not a route.js file. So their kind of file conventions allow you to kind of co-locate some data depending on however you kind of want to do it. Now, like I said earlier, they do provide some different kind of features that can be useful for you. So you can actually create private folders within Next.js by prefixing the folder with an underscore. So underscore folder name. And what this does is the folder is a private implementation detail and should not be considered by the routing system, thereby opting the folder in all its subfolders out of routing. So in this example here, if they created a

underscore lib folder, and they created a page.js file, which would normally be publicly accessible. Well, since they prefixed this with an underscore, that's making this a lib folder, and all of its subfolders not publicly accessible. So, it's making this page.js file within underscore lib. It's not routable. You can't actually access this page.js file, okay. So, they give you the ability to add underscores in front of Fuller's names to make those private. And even if you add a page.js or route.js file within those folders, it's not going to be publicly routable or accessible. Now, they do go on to say that you don't necessarily need to do this. Since if you don't add a page.js or route.js file within your folders, then it's safe to kind of co-locate your data there anyways. But they mentioned that you still might do this if you want to separate UI logic from routing logic, if you want to consistently organize internal files across the project, if you want to sort and group files and code editors, or avoid potential naming

conflicts with Next.js file convention so these are some reasons why you might still use these private folders even when you wouldn't necessarily need to. As long as you avoid adding a page.js or route.js file within your folders, as those are going to be private anyways. Now, their next section of their docs here covers route groups. I cover this in a separate video, so you can check that out. But you can also add route groups for some organization. But my video on that will go into much more depth there. And then you can also use an SRC directory within xjs. So you could put all of your application code within an SRC directory. That's going to be absolutely okay to do. And then you also have module path aliases, which when I first started coding, I was like, this is kind of lame, who cares? But it's actually super nice. So instead of doing something like, you know, importing a button from, and then you have to go back like three directories to get your buttons. So like dot dot forward slash, dot dot forward slash, dot dot forward slash components.

forward slash button instead of needing to do that, you can just use an at symbol forward slash components forward slash button. So, this at symbol is basically like, Hey, go find this components folder and import my button from it. So, these module path aliases just allow for much cleaner imports, which I actually personally like. Didn't care about this at all when I started out, but I've come to realize that this is actually a pretty cool feature here. And then here, they talk about a few different project organization strategies that are common in the day. They can make sense, and they go to say, you know, there's no right or wrong way to do this, but these are just some strategies that people tend to use. So, for one, you could store project files outside of your app directory. So, you might have a components folder or a lib folder, and you might store those at the same level as your app directory. So, you would have components, lib, app; all those would be at the same kind of hierarchy in your application, and then you would just keep your app for kind of routing.

purposes. And only for where you create your routes and your different pages and raw handlers and stuff like that. So I think that is one reasonable way to go about things. They also talk about how you could store project files in top-level folders inside of apps. So you'd have your app folder and then you would have a components folder within your app folder as well as a live folder within your app folder. And then you could also have your kind of routing and pages in your app folder as well. I tend to do things this way, but I haven't really come to a clear methodology that I personally really love. But this is kind of my default of creating a components folder and as well as a live folder within my app directory. And that is kind of within the same level as some of my kind of different routes and stuff like that. But I can also see the argument for why this would also make quite a bit of sense to do up top. And then they also talk about splitting project files by feature or route. So they might create a components

folder within your app folder. But you also might create a components folder within your dashboard folder. So all of your components for your dashboard go into that folder. And then say you have a Blog folder or blog route, maybe all of your components for your blog go into that route. I could also see this making sense, but it could also get a little bit messy if okay now. Now you might have some components that you use across both your dashboard and your blog. And then you have certain components that you use for just your dashboard and your settings folder. And it could get a little bit kind of messy in that regard. So I don't think I would love this route, but this would allow you to kind of co-locate your components to only the kind of routes or pages that are using them, which could have its benefits as well. So those are a few different strategies I've personally kind of defaulted to using. The one where and you keep like a components folder and a live folder within your app directory. But I I can see all these being pretty decent. And it's just going

to kind of depend on what your team likes, and what your team is used to. So, that is it. That is Project structure in next Jazz. Hopefully, this gives you some ideas on how to structure your project, and what may be some good ideas are when it comes to doing that. So, thanks for tuning in to this. I'll see you in that next one.

Next JS Project Structure: Patterns and Techniques for Success

Next JS Project Structure: Patterns and Techniques for Success

스크립트