IDEs already have a solution to the problem of when you have the same file name multiple times

On vscode, when you use ctrl + p is possible to also specify the folder to be searched, so instead of just searching for "layout" you can type "dashboard/layout" and it will be much more assertive

About the convention

I think it would be even better if both patterns (*.layout.js or layout.js) are supported and is up to the developers to define which one they prefer.

There are some more cases where the same name might cause a slightly worse dx:

Error Traces:

React Dev Tools:

Tabs (e.g. Stackblitz):

We can make the DevTools show the folder name to handle these cases. I think we already do that for files called index.js, at least in component stacks.

also relay (facebooks graphql framework) enforces that the filename must be part of the query which doesn't add much debugging value if all files have the same name (see facebook/relay#3889 (comment))

@jon64digital Why would looking at the parent folder name instead of the filename be so hard for you? You’ll have to look at the ancestor folder names anyways if you have several dashboards / settings in different routes to figure out which of them you are looking at. VSCode should show the path in the search field and the breadcrumb of the editor too, so you’ll just have to move your eyes one slash to the left.

As for why, I think the post shows the advantages of using folder names over file names very well.

I think it also makes sense when considering dynamic routes.

💪 I think _layout.js is a good idea, just like _middleware.js, without changing current behavior!
and colocating other files can be done using configurable custom prefix.

this will reduce number of directory in a project.

Easier migration is nice and important, but the easiest migration is when nothing changes and you stay in same system, so you also need to ask whether being able to maintain the names (mostly) is worth not taking the benefits of changing it.

I was about to propose naming _layout and _page myself, however just as an DX improvement like proposed by tuliofaria, not to use files as route segments. This way they will usually stick together at the top when listed and be visually separated from the colocated components.

another like next.js framework UmiJS nested layout, very good, because it contains too much of its own ecology, the new project does not want to continue to use. so I hope next.js improve self nested layout as soon as possible.

I think that ability to co-locate page/route files near each other is more important than easier migration, or fewer folders... One of the most annoying things in the current version of next is just that. The proposed solution is great in my opinion, I would stick to that.

Yes! .js, .jsx, .ts, .tsx are all welcome 😄

The name needs to be page.js exactly. If you do not export a Page component, Next.js will throw an error.

@leerob I think this line needs to be reworded to clarify that the filename needs to be 'page' and the extension can be any valid Next.js extension. Current wording suggests only page.js is valid

Great point, I will fix this.

IMHO the wording should reflect the current pageExtensions configuration that is available in next.config.js. So .md and .mdx could become a valid page.

Presumably the same way you can already do that today with index.js:

-settings
|-[[...catchAll]
|-|-page.js

As @k15a said dynamic segments will still be supported as directory names

In the case where the optional catch-all is the only route, this new syntax seems harder to use.

We designed a multi-page component that developers mount on /sign-in/*. It mounts a bunch of routes on their behalf:

• /sign-in (to start the process)
• /sign-in/first-factor (to verify the first factor)
• /sign-in/second-factor (to verification the second factor)

Currently, we ask developers to mount our component in pages/sign-in/[[...index]].jsx

If I understand correctly, now we'll need to ask developers to mount in pages/sign-in/[[...segments]]/page.jsx

The extra directory is an unfortunate extra step, and this syntax is quite verbose to define a wildcard route.

There are multiple reasons for having directories instead of any file is a page.

• Colocation - You can now colocate components, tests, styles, and stories
• Layouts nesting - You can reason about what layout applies to the child segments as creating a pages/sign-in/layout.js apply to that segment and it's children.
• Additional conventions - As mentioned in the RFC there will be more conventions in the second part regarding where to show loading states through loading.js, once that part is out it'll be even clearer why the directories approach makes sense

Okay - will the presence of an optional catch-all directory remove the requirement for a page.js?

The directory structure may lend itself to removing the "optional" catch-all concept:

• If /foo/page.js and /foo/[...slug]/page.js both exist, then navigation to /foo renders /foo/page.js
• If only /foo/[...slug]/page.js exists, then navigation to /foo renders /foo/[...slug]/page.js

Do most developers want an extra layer of layout/loading/colocation for their catchall routes?

If not, a /foo/catchall.js convention could work. It mitigates the extra folder if developers don't need it, but they can still opt-in via /foo/[bar]/catchall.js

Are server/client components going to be automatically detected, or will we need to follow the naming convertion of .server.js .client.js as proposed by the React RFC?

Note there's an alternative convention being discussed in reactjs/rfcs#189 (comment), which is linked from the post. It is possible the RFC will be updated to it.

How is the layout file handled in a situation of the folder being named [[...params]]? Im assuming it would only be rendered once and not once per depth of params

Could you expand on what you mean exactly, it's unclear to me what you mean with regards to rendering layouts per depth of params.

At the end of the article there's a Intercepting Routes bullet point citing a modal opening on navigation. Just to clarify, is this the same scenario as if I want some content to be shared between, say, /some-page and /some-page/content, where I want the original content of /some-page to not be re-rendered or removed?

The second post will go into the modal case with examples 👍 Basically you'll be able to have a route rendered differently on client navigation (e.g. to open a modal).

Could you expand on what you mean exactly, it's unclear to me what you mean with regards to rendering layouts per depth of params.

Reading back my own question is sounds a bit stupid since multiple params would still only match a single route, which would imply that a single layout would be rendered, but thats what I wanted to confirm. When a url like /multiple/segments/on/the/url matches a [...param] leaf, it still counts/renders the layout.js once and doenst nest it into itself for each repetition

it still counts/renders the layout.js once and doenst nest it into itself for each repetition

Yeah if you have app/dashboard/users/[[...param]]/page.js with a app/dashboard/users/layout.js the component tree will look somewhat like this:

<DashboardUsersLayout>
  <ParamPage /> {/* When navigating between /dashboard/users/tim and /dashboard/users/bruno only `ParamPage` is rendered `/ */}
</DashboardUsersLayout>

This was my first thought when I saw page.js. Would be nice to have a slightly less repetitive naming convention, with a single special character indicating file type, such as an underline or dollar sign prefix.

I agree with this 100%. It's my main complaint about the index.jsx/tsx naming convention. Having several index.tsx files open gets confusing. I understand the reasoning behind it, in next.js but couldn't the route file for the directory have the _ in front of the file name so the compiler knew which file had your component in it irrelevant, to the rest of the file name. Could still colocate tests and style without such strict naming conventions, in fact it might be MORE clear that any file starting with _ is a route. Just my thoughts, I will adapt and use it either way. Love this update!

I agree with the proposal but want to share a trick I always used with Next.js: Symbols in VS Code.
My pages all have an underscore in their name (function name, not file name), so I can easily find & open them with via the command palette together with a keybind.
Same could be applied to all the upcoming files (layout, page, etc.) we're going to have.

Screenshots: https://twitter.com/BennettDams/status/1529051702351085568

Folder names are already part of a route. In a sufficiently big app the last segment may not be sufficient or unique to tell you where you are, so you already need to look at the parent folder name.

This proposal just makes this consistent.

As for editors, they already provide support for showing the ancestor folder in search and usually in the editor as breadcrumbs. VSCode also allows to show it in the title.

I think I would prefer this:

• /app/settings.js Defines page
• /app/settings/foo.js Defines child page
• /app/settings.layout.js Defines layout for /settings and /settings/foo

Besides text editor concerns, I prefer an optional /app/settings directory to add child routes, versus a mandatory page.js in every directory. The latter creates a flow where I have to rename /app/settings.js to /app/settings/page.js when I want to add child pages.

One thing that worries me, though, is that text editors often group directories and files separately. I'm not sure if that's more or less painful than a lot of files with the same name.

Edit: I believe it would resolve the concern from @baiirun above that pages are not actually pages

Yes imo the "_" convention or any other convention is necessary, first it put the page on top for alphabetical order, which is great, then it avoids confusion when "Page" or "Layout" are actually meaningful things in your business domain, which is pretty common
Edit: scratch that I didn't understand that now all pages were literally named "pages" instead of having the name of the last segment. The pattern from the RFC makes sense to me, as "page" behaves like "index" behaves already. If you want a better name for the file, then colocate a better named file that exposes the components, and import it in the page, as you would export some code from an "index.ts".

I get the sense that they are trying to avoid wrapped apps like with Apollo.

In Next.js, we'll probably support getInitialProps for backwards compat. We are also separately considering the use case of "seeding" data from the server during SSR but not during client navigations.

In React, we're also considering these use cases when adding additional support for serializing data through the HTML stream. See reactjs/rfcs#219 for a start of the discussions.

We are also separately considering the use case of "seeding" data from the server during SSR but not during client navigations.

This in particular is really exciting. It's a problem I've been poking at a lot with SWR and haven't really come up with a satisfactory solution.

I'm also curious about this. Will we be able to fetch at the component level?

Longer-term both approaches will be supported but currently Suspense for data fetching is not stable yet and not specifically tied to React Server Components, getting to the result where components are rendered server-side while data fetching happens in getServerSideProps/getStaticProps will be the intermediate state and longer term both will be supported.

The main benefit for fetching data outside of the component tree currently is that it does not create a render-fetch-render-fetch waterfall which is explained in this part of the RFC: https://nextjs.org/blog/layouts-rfc#parallel-fetching-and-rendering

The data fetching will be kicked off eagerly regardless of rendering as we know what layouts / page will be rendered before the React rendering starts.

This diagram from the blogpost explains it visually:

The simplest demo of this would be:

// app/dashboard/layout.js
export async function getServerSideProps() {
    // Simulate intentionally slow data fetching by 5 seconds
   await new Promise((resolve) => {
     setTimeout(resolve, 5000)
   })
   return {
      message: 'Dashboard'
   }
}

export default function Layout({message, children}) {
    return <>
      <h1>{message}</h1>
      {children}
    </>
}


// app/dashboard/teams/page.js
export async function getServerSideProps() {
   // Simulate intentionally slow data fetching by 2 seconds
   await new Promise((resolve) => {
     setTimeout(resolve, 2000)
   })
   return {
      message: 'Hello to the teams page'
   }
}

export default function Page({message}) {
    return <>
      <p>{message}</p>
    </>
}

With this example getServerSideProps for app/dashboard/teams/page.js will be finished before the rendering of app/dashboard/layout.js even starts as it takes 2 seconds to resolve whereas the data for the layout takes 5. Total render would take around 5 seconds.

If you were to fetch data during rendering of Page you'd have to wait 5 seconds, then rendering of Page starts which waits for the data fetching that takes another 2 seconds before the part of the page is there. Total render would take around 7 seconds.

As you can see the timing would grow as you add more data fetching, if you had another layout that took 3 seconds and then another that took 4 seconds you'd end up taking a total of 14 seconds compared to 5 seconds when the run in parallel.

Note: I'm intentionally using large numbers to clearly show the difference, in practice these numbers will be x milliseconds but as shown it's would stack up in a similar way.

Longer-term both approaches will be supported but currently Suspense for data fetching is not stable yet and not specifically tied to React Server Components, getting to the result where components are rendered server-side while data fetching happens in getServerSideProps/getStaticProps will be the intermediate state and longer term both will be supported.

The main benefit for fetching data outside of the component tree currently is that it does not create a render-fetch-render-fetch waterfall which is explained in this part of the RFC: https://nextjs.org/blog/layouts-rfc#parallel-fetching-and-rendering

The data fetching will be kicked off eagerly regardless of rendering as we know what layouts / page will be rendered before the React rendering starts.

This diagram from the blogpost explains it visually:

The simplest demo of this would be:

// app/dashboard/layout.js
export async function getServerSideProps() {
    // Simulate intentionally slow data fetching by 5 seconds
   await new Promise((resolve) => {
     setTimeout(resolve, 5000)
   })
   return {
      message: 'Dashboard'
   }
}

export default function Layout({message, children}) {
    return <>
      <h1>{message}</h1>
      {children}
    </>
}


// app/dashboard/teams/page.js
export async function getServerSideProps() {
   // Simulate intentionally slow data fetching by 2 seconds
   await new Promise((resolve) => {
     setTimeout(resolve, 2000)
   })
   return {
      message: 'Hello to the teams page'
   }
}

export default function Page({message}) {
    return <>
      <p>{message}</p>
    </>
}

With this example getServerSideProps for app/dashboard/teams/page.js will be finished before the rendering of app/dashboard/layout.js even starts as it takes 2 seconds to resolve whereas the data for the layout takes 5. Total render would take around 5 seconds.

If you were to fetch data during rendering of Page you'd have to wait 5 seconds, then rendering of Page starts which waits for the data fetching that takes another 2 seconds before the part of the page is there. Total render would take around 7 seconds.

As you can see the timing would grow as you add more data fetching, if you had another layout that took 3 seconds and then another that took 4 seconds you'd end up taking a total of 14 seconds compared to 5 seconds when the run in parallel.

Note: I'm intentionally using large numbers to clearly show the difference, in practice these numbers will be x milliseconds but as shown it's would stack up in a similar way.

What about a case where I want the settings page to have a different layout from the rootlayout. Like having a separate Dashboard Layout for app/dashboard/settings/page.js has a different layout for app/about/page.js

The main benefit for fetching data outside of the component tree currently is that it does not create a render-fetch-render-fetch waterfall which is explained in this part of the RFC: https://nextjs.org/blog/layouts-rfc#parallel-fetching-and-rendering

This is already possible today with Apollo or Relay. However for all projects without GraphQl the RFC improves (and simplifies) many data loading performance issues quite elegantly.

I have one further question for data loading: How would you recommend to solve recurring data waterfalls? E.g.: inside nested layouts and inside the content you want to load and display additional data only if the user has the administrator role.

You need the request object for personalization of the server render. I think React Server Components don't have access to the HTTP request, but Next can pass it via getServerSideProps.
Could it be an example where both approaches interact efficiently?

Since server-render happens in a "safe-space", where we can fully trust the props object to be sanitized and secured (think passing the current authenticated user for instance), isn't there a risk of confusion when we leave this sanitized world?
Like, I pass current user to Foobar.server.ts. Safe, I can fetch more data based on this information.
I change my mind and pass current user to Foobar.client.ts. Becomes unsafe. Any idea on how to prevent that?

I'm assuming this would be documented in the next RFC that talks about how the framework will use Suspense behind the scenes. Hopefully an example would be included there.

We'll be covering this in part two 👍

I agree with @ervwalter, and want to add a use case that might hinder backwards compatibility that’s being thought of in the RFC.

I can think of a few projects I’ve seen in recent past that already have an /app folder. Sure, one could simple refactor, but that’s usually easier said than done in some cases.

Making it configurable would be ideal as @jeremytenjo has said. Would really help incremental adoption for those who want to try this without changing root business logic.

I too agree that app is maybe not the best choice as people might already use it to group their application files, something like

<project-root>
    - .next/
    - app/
        - components/
        - lib/
        - pages/
    - node_modules/
    - next.config.js
    - package.json
    - ...

...so the pages path would be <project-root>/app/pages.

With the new proposed app folder it would become <project-root>/app/app which might trigger people's OCD... 😁
I support the proposal to name that folder routes or maybe something else, like views (not as great, but IMHO better than app), if you don't want to use the same as Remix 🙄.

routes as default and making it configurable in next.config.js seems like the best option :)

I also strongly prefer using “routes” for this instead of “app”. Because I think it makes more semantic sense, but also because we have thousands of Blitz apps using “app” to organize all application code.

The app folder should definitely be configurable. I don't see any reason not to.

One use-case I have in mind is about dealing with JWT authentication and Refresh tokens.
Today, in our application, we have a withAuthentication() function that we use to wrap the getServerSideProps() of pages that require authentication.
In this function, we deal with cookies to verify that the user is logged-in and if the access token is valid and still active. If the access token has expired and there is a refresh token available, we need to refresh the access token. This means regenerating a new token by checking that the refresh token is valid and matching a user, setting the new access token in the response cookies and also pass the new access token to the wrapped getServerSideProps() so that it can use it to authenticate when doing API calls (remote GraphQL API in our case).

With the current state of the RFC regarding parallel data-fetching, I feel like all segments getServerSideProps of a given page would need to handle the refresh token logic. Instead, we should only do it once in the first layout requiring authentication.

Auth for parallel loading can definitely be a headache. But, I don't believe getBlockingServerSideProps is strictly necessary. An alternative design can leverage a 307 redirect.

Let's use the request from the illustration as an example: /dashboard/settings

When the request comes in, getServerSideProps runs simultaneously in DashboardLayout and SettingsPage.

Let's say SettingsPage receives an expired JWT and throws an error to cancel it's rendering.

And, let's say DashboardLayout does three things:

1. Refreshes the JWT
2. Issues a Set-Cookie header with the new JWT
3. Issues a 307 redirect to req.path (effectively retrying the same request, this time with the updated cookie)

When the retry request is received, the JWT is updated and your withAuthentication function will work fine across all getServerSideProps.

This same design works for "protected routes". Let's look at the same request to /dashboard/settings, but assume there is no JWT instead of an expired JWT.

SettingsPage receives no JWT and throws an error.

DashboardLayout receives no JWT and issues a 301 redirect to /sign-in, where the user can sign in.

This is moreorless how Clerk solved this problem for Remix, which faces the same challenges.

The solution depends on two things:

1. DashboardLayout has a way of issuing a redirect and setting a cookie from its getServerSideProps
2. The throw in SettingsPage doesn't supersede the redirect in DashboardLayout.

Thanks for sharing details regarding the authentication flow. In our original implementation, we were actually doing the refresh token logic in an Edge Middleware. This middleware was actually doing a redirection on req.path because we were not able to pass/update data from the middleware to the page getServerSideProps (the cookie in this case). We actually had to stop doing this because Next.js router was ending up in an infinite loop - crashing the browser when doing a client-side navigation where the getServerSideProps of the target page was returning a redirect 😅

Regarding getBlockingServerSideProps, it's not only useful for authentication but anytime data fetched from a parent layout is needed in a nested one. Such as the /me example of @dexter-atob.

Love this discussion! Yeah my use-case using another framework was a bit different. Basically, we had to show different routes depending on what access the user has. If they didn't have admin access, but they attempted to access an admin route, we'd just redirect them to a 404 page. On every nested route that used a loader we would add a call to the /me route. On nested routes, we had to call the /me route to grab the user's role/features. There's an obvious argument that could be made here where we'd just store the claims in JWT token and in order to get the newest claims the user would need to logout and log back in or refresh their auth token, but I really just wanted the loader to make a request at the parent route and then provide that data to child loaders.

Some other solutions I looked into: potentially using a request cache so that for the same request the loaders could race to create the promise and then the promise would be awaited. The problem was that there was no way of distinguishing the request from another, and I didn't want there to be request collisions between users (the system was multi-tenant so this would have been REALLY bad). I also looked into adding some kind of request ID but I would have needed to make some bigger changes. And another solution I looked into was a server-side cache of some sort, potentially using Redis, but again super heavy-handed and then we had the problem of having to invalidate that cache somehow.

Anyhow I gave up on that framework and just went back to plain old CSR.

I can think of a workaround for this problem given the current architecture of Nextjs layouts, but I'll admit it feels a bit hacky...

A module that holds your shared data, and provides async getters for it. This module is imported by all files in the layout chain that need the common data, and they call the getter that would otherwise call the data source (be it DB, an HTTP request or whatever your source of truth is) multiple times.

In SSR, the getter call could take the request object, and check it against a WeakMap. If it doesn't exist, set the request as the key in the WeakMap, with the promise for the data as the value. Later, when the same getter is called by another route in the chain, return the promise for that request. Because it is a WeakMap, after the request is handled, the garbage collector should remove the promise from the weak map automatically. From the view point of the caller, they all just await the promise they got from the WeakMap. Whoever calls it first will block on it (while other ones will continue to work until they too need the same data, and then they all wait), and whoever calls it after that will essentially get the data immediately.

You could have multiple different operations stored in the same WeakMap value, stored as an object of named promises, and return the corresponding one based on the getter call, always initializing the "placeholder" object to an empty one when the request object is not an existing key in the WeakMap.

You're sacrificing a tiny bit more memory than you would otherwise (allocating the module and the WeakMap itself), in order to get great speed saving (no second data source lookup + parallel execution where possible) and DX (no passing down of data in a waterfall).

On the client side, the same approach can be used, except that you would not pass a request - just maintain the entire thing as a singleton.

For "bonus points", in both client and server side, you could spawn a worker thread for the actual storage and retrieval. A thin client on the main thread would merely resolve the promise on a message from the worker. That's once again some more memory (for the whole second thread...) for the luxury of letting everything else happen on the main thread at the same time. That last part is essentially what comlink is for.

Ignore being forced into a server rendering strategy

Adopting Server Components doesn’t mean that the route will be SSR’d on every request. If it doesn’t have SSR data fetching (getServerSideProps) in all its layouts, the route will be statically optimized at build time just like what we have today.

Adopting Server Components doesn’t mean that the route will be SSR’d on every request. If it doesn’t have SSR data fetching (getServerSideProps) in all its layouts, the route will be statically optimized at build time just like what we have today.

That's really good to hear. I didn't realize that.

@shuding Does that imply that you can statically render parts parts of the tree and dynamically render others? That would actually be really cool.

@mAAdhaTTah In some cases, yes! The exception will be “static sub-layout under dynamic layout”, where the static sub-layout can’t be real static anymore, because you can pass dynamic data (via context) to it.

Circling back @timneutkens you mentioned that my earlier bit would be covered by part 2, but I don't see it explicitly mentioned here. I think I get the picture on how it's a paradigm shift (no need for _500, _404, or _error because they're no longer going to be page-wide errors. Instead, they'll be component-level tree errors. That being said, I think you would probably still want layout-level or page-level handling for 404 and 500.

I saw that _app was mentioned; however, I saw no reference of _error, _404, and _500. Will there be equivalent files per segment? Since we can potentially expect error responses from multiple data fetching methods, will either the methods OR the custom components be getting an updated API to allow developers insight into which data fetch caused the issue?

You have a really good point. IMHO a helper method (probably in the form of a hook) should tell how deep you are in a subtree, shared data/context from parent/child segments and a way to conditionally refresh a parent segment data.

Remix offers hooks for those scenarios (like useMatches) and allows to use segment data in any layout with an array of all the nested parts of the route. Something similar will definitely need to exist.

There's a note in the RFC regarding refreshing data on a parent route that could also be relevant: "It will be possible to force a re-fetch of data higher up the tree. We are still discussing the details of how this will look and will update the RFC."

We're currently using React Router and looking into migrating to Next for a while. Nested Routes will definitely make this easier, but we heavily pass data from parent route segments to child route segments as well. Is it allowed to have a function as children, so we can do something like this?

// customized example from the blog
// app/blog/layout.js
export async function getStaticProps() {
  const categories = await getCategoriesFromCMS();

  return {
    props: { categories },
  };
}

export default function BlogLayout({ categories, children }) {
  return (
    <>
      <BlogSidebar categories={categories} />
      {children({ categories })}
    </>
  );
}

I'd like to avoid Context, because it increases the indirection and is more verbose. It would of course also be nice if TypeScript can properly check this (e.g. children which is passed to BlogLayout must be a function which accepts { categories }).

You will have to use something like Context for this case (will add examples for this). A layout and its children aren’t simply wrapped together like normal components, but can be a Server/Client Components pair:

https://nextjs.org/blog/layouts-rfc#interleaving-client-and-server-components-using-the-children-prop

So actually all the levels of nested layouts can be rendered in different environments, and we can’t pass any arbitrary props between them (e.g. a callback function) but only serializable ones, that’s why we need a new way to do this.

Can React Context cross the Server/Client boundary like that? My understanding is you're going to end up with Server & Client Context as separate things, which would make using Context for this difficult/impossible.

You have a really good point. IMHO a helper method (probably in the form of a hook) should tell how deep you are in a subtree, shared data/context from parent/child segments and a way to conditionally refresh a parent segment data.

Remix offers hooks for those scenarios (like useMatches) and allows to use segment data in any layout with an array of all the nested parts of the route. Something similar will definitely need to exist.

There's a note in the RFC regarding refreshing data on a parent route that could also be relevant: "It will be possible to force a re-fetch of data higher up the tree. We are still discussing the details of how this will look and will update the RFC."

This sounds like a good option. I think this kind of functionality is essential.

I have a Parent component where I want my logic and state to live. Nested within that Parent I want to navigate through multiple Child pages which all use the state passed down from the Parent.

Without using Context this isn't possible, but for some simple things it seems like overkill. There are ways to get the React Router working within Next.js projects, so it must be something they can build into Next.js?

Even a very rough estimate would be helpful i.e. 6-8 weeks? 3-6 months? Sometime in 2023?

We still are not at the point where we can provide a public estimate for this, but we have several members of the core team working on this as their primary project, and are already months into implementation work if that helps at all. As soon as we are confident enough to drop a public estimate we will do so, and we will also offer testing on a canary build before stable release as we do with all nextjs features 😁

For your example, you could use the next/head component or the garmeeh/next-seo package to add page specific tags in the HEAD.

Okay, what if I just need page data to pass to other components that are in the root Layout?
In general, what is the strategy for passing props from a page file up to a layout file?

You could use the Context API and share data through multiple components in the layout tree using hooks.

Context should be used sparingly, so it seems like more of a band-aid solution. It's strange that nothing has been built into this layout project that allows for this type of props passing.

I don't think that's inherently a bad idea. Context is a powerful solution that if used correctly, or with the help of a third party package like use-context-selector, allows you to share data throughout your application without the need for a state manager or some other complex means of data sharing.

It's robust and reliable and by the looks of it it may be the best solution for your needs, unless you have some strict requirements that prevent you from using it.

Hidden both comments as they're off-topic. The first comment is completely incorrect and seems to be an assumption not backed by any data.

@sopuku keep an eye on https://nextjs.org/conf 🙌