Route groups allow you to organize your project files into logical groups without affecting the URL path. To demonstrate a use case, we have a simple application that has a route homepage. This page displays home suite home, and indeed, if you visit the default route, we can see it in the browser. It's easy for the homepage to get lost in the noise amongst the other files. Additionally, if I want to search for the homepage, my only option is to search for page and make sure that I select the home one. Fortunately, we can fix this by using a route group. A route group can be created

by wrapping a folder's name in parenthesis. So here I'm creating a route group called home. Any folder that has its name wrapped in parentis is ignored when doing URL path matching, which means that this home portion is not going to become a part of the URL. And indeed, if you visit slash we see our homepage. Notice that home is not a part of the URL. Additionally, if I ever want to open up the homepage within my code files, I now have an easy way of doing that by simply searching for home. The most common use case for a route group would be to co-locate similar routes in a folder without

affecting the URL structure. As an example, we have two author related routes within our application, we have a login route that shows the login text and a register route that shows the registered text. These routes show up at slash login and slash register. We can make it easier to navigate the project source code by co-locating the things that are related to oath. For this, we create a new route group by using parenthesis. And as we know this is not going to become a part of the route. We move the login and the register pages into this route group.

And now our teammates have a nice way to find all the pages related to AU, while still preserving a simple URL structure for our website users and often overlooked utility of the next year's route group is that it allows you to isolate features like layout and loading screens to specific pages. As an example, we have a dashboard section within our website that has a root page that takes quite a while to load. Here we are simulating that by awaiting a promise that resolves after three seconds. So to give our users a better experience. While this page is rendering, we decide to create a loading UI in loading TS six.

And indeed, if we try to visit the dashboard right now, we see the loading screen and eventually the dashboard pops into view. But what might surprise you is that if we visit a sub route, for example, dashboard slash marketing, the same loading screen is going to kick in, which might not be appropriate for our use case. So your mission should you choose to accept it, is to make sure that the loading screen only impacts this route page. And no surprise, you can achieve this by using the route group. We create a new route group, doesn't matter what you call it. We choose to give it the name route,

and then we move the page and the loading screens into this route group. And now this loading UI is not going to impact the marketing pages because it is in a separate folder, and we can verify this from the running website. If you visit the dashboard, we get the loading ui. However, if you visit dashboard slash marketing, we no longer get the incorrect dashboard loading ui.