Next.js - understanding page routing

0. What will you learn?

In this article you will comprehend how file-system based routing works in Next.js and how to use it properly in different cases that you may encounter during your work with Next.

Note, that for this article I created a new project using create-next-app package with typescript but you can use any different configuration using pages router

1. General explanation

Next.js has a file-system based routing, which means that to describe what routes your application has - you create corresponding folders and files in a special pages folder.

Let's look at an image to better understand how it works:

In your project you should have a folder named pages. This is a pre-defined by Next folder exactly for routing. You cannot change its name.

As you can see, there are already files inside. I will briefly tell you what they are but I won't stop here as it's out of scope of this article.

_app.tsx - is a file that is generally used to modify props going to your pages, add common layouts that will remain consistent between different pages, or add logic that repeats from page to page such as analytics tracking or language context.
_document.tsx - is a place where you can modify your <head /> and <body /> tags and add common for all pages metadata.
index.tsx - is where the routing begins. This is the page that will be served from your root / route. For example, if your domain is example.com, then example.com/ is the path that will trigger index.tsx page to render.

2. How file-system based routes works

Each file and folder inside of the pages folder represents a node in the url path. Let's take a url and see how it works: example.com/{articles}/{nextjs}/{routing}
The words separated by slashes and taken into {brackets} are nodes in the path of the url, which I am going to address further as segments, just as Next.js does. These segments are what we can define using the pages folder.

Examples

Now I'm going to break down case by case different types of routes.

One-level deep routes

example.com/profile

📂 pages
    profile.tsx

This one is pretty straightforward. If we need a path like this, then we just create a .tsx file, with the name of the segment in the root of the pages folder.

Nested routes

example.com/profile/settings
example.com/profile/settings/privacy

📂 pages
  📂 profile
      📂 settings
          index.tsx
          privacy.tsx

The second one answers the question of how to create nested routes. With folders!
Each nested folder represents a segment in the path.

If a segment is described with a folder but you need it itself to represent a page, then you simply add an index.tsx file inside that folder. In this case /settings segment contains subsegment /privacy but it will be an accessible page too.

Dynamic routes

example.com/articles/next-js-routing
example.com/articles/how-to-write-clean-code
...

📂 pages
 📂 articles
     [id].tsx

This one is a bit more complicated, because it addresses the problem of dynamic urls.

There are cases when we can't know the exact amount of pages nor their names. A good example is a blog, which has lots of articles and each article has its own url.

In such case it would be impossible to create a file for every new article that appears on the blog, that's why by using the syntax of dynamic paths we show Next that this is not just a static path but rather an indicator that there may be multiple pages rendered by the same component. And these pages will be generated at request time or prerendered at build time depending on the rendering strategy that is used.

Syntax of Dynamic Paths

a. To let Next know that this is a dynamic route we take the name of the file in square brackets [].
b. The name in the brackets doesn't actually represent the segment name. You can think of it as a variable, that will be transformed into a real value when a request reaches the website or at build time, again depending on the rendering strategy.

Catch-all Segments

example.com/shop/categories/phones/accessories/...

📂 pages
  📂 shop
     [...categories].tsx

Here Next will match anything that will be in the path after /shop.

This is very useful for things like online shops where there are numerous categories, types of products, etc. that cannot be predefined and will only be available after collecting them from the server, for instance.

If you have a question of how it will work if absolutely any words can be put in the path, the answer is simple. The validation happens in the code. There are different methods, from simple segments validation to using static site generation with predefined paths.

Optional Catch-all Segments

example.com/shop
example.com/shop/categories/phones/accessories/...

📂 pages
  📂 shop
     [[...categories]].tsx

The last one is the same as the regular catch-all segments except for the fact that it will match /shop too. Unlike the regular catch-all that would ignore /shop.

This is it! 🔚
Thank you for reading the article, hope you enjoyed it!
I will be glad to hear your feedback :)

Blog