We will look at practical examples of the various router files in their own individual lessons. But in order to appreciate the true breadth of what the next year's router offers, this lesson will provide you with the reference bird's eye view at its score. Next year's works on top of file-based routing. What this means is that if we create a file on the file system within the app folder, for example, page do tsx, it'll automatically service requests for the root URL. Note that we are using TypeScript and TSX for this course, but they can also be JavaScript files, for example, JS or JSX, as long as the default export is a react component.

Next JS will pick it up and render it as a part of a response. Now we can also create folders within the app directory. For example, a folder called Hello that contains a page TSX and next JS will automatically pick it up as a part of its routing. So when a request comes in for slash hello, next JS will render the page do TSX file found within the hello folder and use that to service the request as we've discussed in a previous lesson. Next, JS also supports API routes, and they also work on top of file-based routing. So within the app folder, if we create a file called Router Ts, next J,

we'll use this file to service any S TT P requests that come in for slash. It can be a get post or any other HTP method. And similar to pages, we can put our routes within folders as well. So if we create a route Ts within a hello folder, this is what next DS will use to service any HTTP requests that come in for slash hello. Now, question that you might have at this point is what happens if we create a page TSX and a router Ts within the same folder? Webpages also work on top of HTTP when a request will come in for slash faq. Next JS will want to render page tsx and

therefore this particular route file will be considered invalid. The solution to this problem is pretty simple. Don't put pages and routes in the same folder within the FAQ folder. You can have page TSX to service slash faq, and then you can create a separate folder called API for the router ts file, which will be used to handle FAQ slash api. That's the basics of routing, but let's dig into some advanced patterns. We can also create route groups to organize our code a bit better. We know that we can create a file page, do DSX within the app folder to service route slash requests,

but it's common to refer to this page as the homepage. So we can actually create a folder with round brackets called home folders within round brackets are called route groups and are not used as a part of the route matching. So even though we have moved our page TSX into the home folder, it is still used to match slash. Another feature of the router is private folders. If you create a folder that starts with underscore, that folder is excluded from next year's routing. So even if you create a file called Page tsx, it'll not be used for any routing.

You can think of private folders as safe folders, so you can put any utility over here without worrying if it's magically going to become routable. Another Feature of the router is dynamic route segments. We can use query brackets for any folder name. For example, hey, we have a folder course slug within the course folder, and this core slug will match any single segment within the URL, for example, slash course slash react slash course slash next, yes, but it'll not match multiple segments. So if we have slash next J slash basics, these are actually two route segments

and they will not match this particular route. If you want to match multiple segments, we can actually create a catch all dynamic route. Catch all segments are also created with square brackets, but then the matched portion needs to start with triple dots, so a page within this particular folder will match anything that starts with slash lesson. So slash lesson slash next J is fine slash lesson. Next J routing is fine. Next JS routing advanced is also fine. We can actually read the value for what is matched and we will cover that in our dynamic routing lesson. The next J router also supports layout components

for common UI portions. For example, we can create a layout of TSX next to page tsx, and when a request comes in for scratch, next J will render out the layout and then pass in the page as children. Now, at this point, you might be wondering why do you need layout of tsx? 'cause after all, you could render out the layout as a part of the page tsx. But the key reason over here is that layouts support nesting as well. So if we create another page under the courses folder, when a request will come in for slash courses, next ts will preserve the layout

that it has already rendered and just rendered the courses page and pass it to the existing layout. Another feature supported by the next year router is loading components. We can actually create a file called loading TSX next to our page, and now when a request comes in for slash next year will start rendering the default export of the loading file. And in parallel also start rendering the page component. While the page component is still rendering, the user will be presented with the loading component and once the page rendering is complete, next, yes, we'll seamlessly swap out the loading

for the actual page the next year. Router also supports parallel routes. So within the app folder we have our layout component, we have the page component, and then we can create a folder that starts with at, for example, at team that contains a page, an at individual that contains a page. And when a request comes in for slash next, yes, we'll render the page, the at team page and the at individual page in parallel, and all of these results will be passed to the layout component. Of course, the route page is going to be the children,

but the parallel routes are passed as named slots. So because the folder starts with add team, that component is passed in as the prop team and add individual is passed in as the prop individual. Another advanced supported by the next year router is intercepting routes. So consider a simple folder structure where we have a login folder that contains a page tsx, and then a lesson folder that contains a page. Now, as you would expect, slash login is serviced by login slash page, and slash lesson is serviced by lesson slash page. Now at this point, if the user is on a lesson page

and we ask them to log in, they will be taken to the login page and this will be a full page reload. This will result in the user losing some of their context, so we can actually do something better. We can create an intercepting route within the lesson folder. Intercepting routes are created with round brackets that contain dots within them, and a triple dot over here means that it is a route level intercepting route. So we are intercepting the route login folder. Now, if the user is on a lesson page and we ask them to log in, the request will be intercepted by our intercepting route and we can do something custom over here.

For example, within the intercepting page dot tsx, we can use a model for the login component on a cold request to slash login. The full login page is displayed and on a login request from the lesson page, a custom login page can be displayed in a model. As you can see, a lot of thought has gone into building the next J router. Of course, there is a lot more to routing in next JS, and we will discuss that in detail throughout this course with practical code examples. Thank you for joining me and I'll see you in the next one. I.