A layout in next JS is a user interface component that is shared between multiple pages. You can define a layout by default, exporting a React component from a code file called layout. For example, within the app directory, we create a page component as well as a layout component. And now when a request comes in for slash, which would normally only be served by the page, next case we'll render out the layout component and passing the rendered page component as the children prop to the layout. Let's demonstrate this By creating a new page under the dashboard route, we render out a simple heading, and if you were to visit the page right now,

that is all what we would see. Now let's create a new layout file under the dashboard folder. The next year's contract for a layout file is that it must export a default component, and this component must accept children as props. We can use the past in children to place them in a specific place and even add additional components. For example, here we are adding a simple footer, so now if you visit the dashboard route, we can see this layout component that displays the footer along with the children, replaced by the dashboard page contents. When we provide a layout component for a route, it is also automatically used for all sub routes. We know that if the layout on the page are next

to each other next year renders out the layout and passes in the page. But in addition to this, for all of the sub routes, for example, a subro under the courses folder, next case will actually render that page within the same layout. What's more is that as we navigate between slash and slash courses, the layout will stay mounted and the only thing that will change will be the past in children prop. Let's demonstrate this with the code example. We've already seen that the dashboard layout is displaying the page that is next to it. Let's create a sub route called subscriptions by creating a page under that folder, just like the root dashboard page renders out a simple

heading, the dashboard subscriptions page will also render a simple H one. On the dashboard route. We can see the page rendered heading along with the footer. And similarly, if you go to dashboard slash subscriptions, we see the H one rendered by that specific page along with the footer that is rendered by the layout, which is coming into play for both of these routes. On client side, navigation between routes that have the same layouts, the layout components preserve state, remain interactive and do not render. To demonstrate why this is important, we will create a component that maintains some local client side state. The component we are creating is a dropdown menu

for the dashboard that preserves the state, whether it is open or not. We create a simple button, which allows the user to toggle the state between open and closed, and then when it is open, we will render out a list containing the links to different routes within the dashboard. If next days didn't have the feature of layout pages, you would think that you could just add the menu manually to the different pages within the dashboard, but you would be missing out on a key feature offered by layouts. React is actually not able to reconcile the same component between different pages, so even though the different pages are rendering the same component every single time we go

to a different page, the component is completely blown away and rendered from scratch, which is why we lose the state, for example, whether it is open or closed. To fix this and make our code Simpler, we remove the common component from the individual routes and instead render it within the layout component. With these modifications in place, let's take a look at the application within the browser. Within the ui, as we navigate the different routes, you can see that the state of the menu, whether it's open or closed, is preserved and it's within our control whether we want the menu to be open or not. Every next year's application actually needs

to have a layout file at the root of the appy, and it is therefore called the root layout. Since it is required no surprise within our sample codes, we've always had this file. Next year's has a special requirement specific to the root layout file. It must render an HTMO and a body tag. Beyond that, you are free to do what you want. For example, you can place some common user interface over here that will be displayed throughout your application. Here we are rendering a fab or a floating action button, which links to our website With this code in place, if you visit any route within our application, it'll still cascade over to the root layout,

which is why we will always see this button. You can even provide layout files in sub routes, which allows you to nest the layout components. Consider the case where we have a layout in the route and then we have a courses sub route page. If we create another layout under the courses folder, when a request comes in for slash courses next year, we'll render the route layout and then pass in the rendered child layout as the children prop, and for that child layout, it'll pass in the courses page and we don't actually need to build a new demo in order to demonstrate this concept as it is already happening within an application.

When the user visits slash dashboard, the page component is passed as children to the dashboard layout component, which is then in turn passed as children to the root layout component, which is why in the final result shown by the browser, we can see the page as well as the dashboard layout that adds the menu as well as the root layout that adds the fab. We are only using two layout components over here, but you can ask as many layout components as you need for your desired use case.