Next JS Project Structure: Patterns and Techniques for Success

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 nexjs 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 rob.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 so 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 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 they're 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 ad 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 pretty cool feature here and then here they talk about a few different project organization strategies that are common in the day then 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

Channel: Code Ryan

Views: 8,799

Keywords: coding, programming, frontend engineering, code, software engineer, next js, react js, javascript

Id: WaFBiDgqctY

Length: 11min 23sec (683 seconds)

Published: Wed Aug 30 2023