Would be cool if that wrapper could also allow for rendering stuff for all routes.

For exemple rendering a specific header above every route in a folder without having to include it in every single route or a global navbar (and so on).

Would be cool if that wrapper could also allow for rendering stuff for all routes.

For exemple rendering a specific header above every route in a folder without having to include it in every single route or a global navbar (and so on).

Yes @antoinegag! That's what I meant by "set up a layout from there" exactly. Being able to do it this way would reduce the need to use external libraries like this one to make easy layout groups.

I really like the idea of having a built-in mechanism like this one, it's something I've had to re-create in a couple of different Next apps so far.

I wonder whether tying this to directory tree/routing might be overly restrictive, though. I could see people wanting to specify shared wrapper/layouts with more granularity than what this would allow (i.e. on a page-by-page basis). Maybe a named export on the page could be used to reference a wrapper/layout instead? I guess that would make it more annoying to have the same wrapper used on all pages, so maybe that is just a different proposal with a different set of use cases :)

This is an interesting proposal! My initial reaction was "ugghh, that sounds complicated". I've yet to fully grasp the difference between _app and _document, and I'd prefer to not have to learn about _index.

Though on second though, I'm growing to like it! Especially the Layout part of it, which allows for much easier nested layouts compared to the getLayout pattern.

@apkoponen To enable both nested layouts and deep-nested paths that don't share layout, I'd imagine this to be configurable. Maybe even by importing ExampleWrapper2 in ExampleWraper3:

import ExampleWrapper2 from "../_index"

export default function ExampleWrapper3(props) {
  return (
    <ExampleWrapper2>
      <h1>This is a header</>
      {props.children}
    </ExampleWrapper2>
}

Some more questions:

• would _index have support for getStaticProps or getServerSideProps?
• what are the tradeoffs of this proposal compared to the getLayout pattern?

You all might want to look into SvelteKit's nested layouts for inspiration which sounds like it is exactly this.

https://kit.svelte.dev/docs#layouts-nested-layouts

EDIT: As mentioned on Twitter there's also a Nested Pages feature in Nuxt that can inspire.
https://nuxtjs.org/examples/routing-nested-pages

A more “vanilla React" approach would be awesome.

I definitely think we need a more first-class solution to nested layout.

I think tying it to the folder structure would be limiting or at least be a paradigm where it forces devs to structure the paths in their app in a way that allows the sharing of state. For example, if someapp.com/home and someapp.com/data/1 share the same layout or state, I’m not sure how the proposed solution would resolve the issue.

An alternative API might be similar to the “Bonus” solution outlined in Adam Wathan’s Persistant Layouts article.

I could see 2 functions:

1. getLayout
2. getLayoutProvider

The combination of these functions can be used to provide shared UI and shared state in any route; however, at that point maybe you’d only need getLayout since you could put providers there anyway.

This would be extremely helpful in building or using component libraries with next.js 🚀

Very interested and needy solution.
Especially the layout part.

Having constant layout patterns across a folder is very much needed for my application too.

I would really like to see this in next! We currently attach a getLayout method to page components to compose layouts in the _app component but this would really cut down on a lot of the repetition.

It would be great to have the ability to control whether nested layouts overrode or composed their parent layouts.

It was amazing literally 5 minutes into converting a react app to next I had this epiphany and thought surely this is supported. I imaged it worked just like _app did in the root of pages. I created a new _app file in my sub directly and coded up a quick test to confirm it worked, and sadly learned that I was highly mistaken. Now off to beat my head into my desk as I try to implement some form of the getLayout algorithm into our application everywhere.

Related: I just published documentation on how you can currently handle layouts with Next.js. To be clear, this is documenting what already exists, not solving this proposal.

Thank you for this proposal! We are continuing to investigate built-in layouts support 😄

I love this idea, I've often thought of the _layout.jade file-based wrapping that I used years ago in Harp.js, but never thought of it as a way to provide data as well.

FWIW it looks like Gatsby 4 has caught up to this idea too:

For inspiration purposes only I post my Gatsby Plugin, where you can add layouts – or all kinds of wrappers, even nested wrappers.

In the README file there are a lot of details.

https://github.com/tujoworker/gatsby-plugin-wrap-pages

I works even inside your own plugin. Which makes it a very interesting to use for micro frontends.

But native _layout.tsx support in Gatsby v4 would be amazing.

_layout but for API routes could solve the issue of startup code: #11686
In this case the layout would be middlewares common to a set of pages. That would prevent having to call "connectToDb()" in all API routes for instance, instead you'd do it in the API route _layout to feed a context, like we do in graphql.
The nesting let's you control on which set of route the middleware is applied, eg ignore routes that don't require a connection to the db.

I've solved this with @ceteio/next-layout-loader!

It automatically loads pages/**/_layout.tsx files, intelligently wrapping them around pages/_app.tsx based on the current route:

// pages/_app.jsx
const filename = preval`module.exports = __filename`;
const withLayoutLoader = codegen.require("@ceteio/next-layout-loader", filename);

// The magic lives here!
export default withLayoutLoader(({ Component, pageProps }) => (
  <Component {...pageProps} />
));

// pages/dashboard/_layout.jsx
export default function Layout({ children }) {
  return (
    <div style={{ backgroundColor: "#e2e8f0", padding: "1rem" }}>
      {children}
    </div>
  );
}

// To hide this layout component from the router / build pipeline
export const getStaticProps = async () => ({ notFound: true });

// pages/dashboard/index.jsx
import NextLink from "next/link";

export default function User() {
  return (
    <div style={{ backgroundColor: "white" }}>
      <NextLink href="/">Home</NextLink>
    </div>
  );
}

export async function getStaticProps() {
  return {
    // props are also passed to _layout components
    props: {
      greeting: "Hello world"
    }
  };
}

Check it out:

• Repo: https://github.com/ceteio/next-layout-loader
• See it in action on Codesandbox: https://githubbox.com/ceteio/next-layout-loader/tree/main/example

This is functionality I would very much appreciate

I tried out sveltekit recently, and this one of the bigger niceties of sveltekit that I am missing in nextjs.

https://twitter.com/leeerob/status/1521713571377287171?s=20&t=3ANpHD6sbd2n05psZjmbow