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.