Original subtitles

We now have a few different pages

in our web application.

Now, you may have been wondering why we need

to create a separate folder for each route,

with a "page.jsx" file inside it.

In fact, the previous approach used

by Next.js was in a way simpler.

With the old Pages Router,

the "/about" page for example would be

in a file called simply "about.jsx",

directly under the top-level "pages" folder,

without the need to create a separate

folder like with the new App Router.

So why did Next.js decide to adopt

this new folder structure,

that seems more complex?

The reason is that this way we can put

multiple files inside each folder,

providing different bits of functionality

for the same route.

For example, this approach allows

us to define nested layouts.

I'll give you a quick demo of

how that works in this video,

but be aware that at the end I'll throw

away all the changes I'm about to make,

because we don't really need this

feature in our app right now.

I always recommend watching

each video in full anyway,

before you make changes to your own project,

if you're following along.

But that's especially true for this video.

Now, we have a "layout.jsx" file

directly under our "app" folder.

We know that this is like a template that

will be applied to all the pages.

If we open the "/reviews" page for example,

this one also shows the "header" and

"footer" defined in the RootLayout.

But we can also create a layout

for each separate route.

Under the "reviews" folder we could create a new file,

called "layout.jsx".

Note how we now have two files directly

under the "reviews" folder:

"layout.jsx" and "page.jsx".

Both these files apply to the "reviews" route.

That's why we need a separate

folder for each route,

so we can have multiple files inside it.

In this new "layout.jsx" we can define elements

that only apply to the "/reviews" path.

The browser shows an error at the moment,

because our layout file doesn't

export a React component yet.

We just need to create a component here,

let's call it "ReviewsLayout".

And, just like the RootLayout, this will

receive the "children" as a prop.

Here we can return some elements

specific for this route.

Let's start with a simple "div"

with the "children" inside,

just to make that error go away.

You can see that the page is working again.

There's no visible difference, because

we just added an extra "div".

But note how we still see the "header" and

"footer" provided by the RootLayout.

So, this layout will be inserted

into the RootLayout.

That's why they're called "nested" layouts.

This is useful if we want to add some

elements specific to this route.

For example, we might want to show a menu bar,

with some options specific to the review pages.

If we save this layout,

you can see that the "reviews menubar"

is displayed below the header.

Let me add a border to this

"div" to make it clearer.

I'll use an inline style, even though

that's not a good practice,

because we haven't covered styling yet.

We'll talk about that later in the course.

But with this style, you can see a red border

around the elements added by this layout.

A common use case for nested layouts

is to add a side bar.

Something that we can achieve by setting

the container div to use flexbox.

So the first child element will

be displayed on one side.

And we'll need to wrap the

"children" in another div,

to display them in a separate block.

This is just a crude skeleton,

but you can see how this allows

us to display a side bar.

I'll go and put a border around the

elements in the RootLayout as well.

We can show one around the header,

but maybe with blue as the colour.

And let's do the same for the footer as well.

This way we'll see in blue the elements

provided by the RootLayout,

and in red those added by the ReviewsLayout.

Now, an important point is that the nested

layout applies not just to the ReviewsPage

but to all the pages inside this path,

like the Stardew Valley page.

You can see that this one also shows the side bar.

And the same will be true for the other review,

that is Hollow Knight.

However, the ReviewsLayout will

not apply to the HomePage,

nor to the AboutPage,

because those are not under the "reviews" segment.

These pages will only use the RootLayout.

Only the pages under the "reviews"

segment will show the side bar.

We could use this feature to display

some filters for example,

allowing the user to search the reviews,

or something like that.

Nested layouts can be quite powerful.

But, as I mentioned at the beginning,

we don't actually have a need for this

feature in our app right now,

so I'll delete the ReviewsLayout at this point.

And also remove the borders

from the header and footer,

that was just a quick way to show you which

elements came from which layout.

In the next section we'll also see how

layouts are not just a convenient way to share

common elements across a group of pages,

but they also affect how each page is rendered,

including when navigating

from one page to another.