In /app directory, is there any way to pass data to the layout even statically?

[zackdotcomputer]

I've run into an issue where the designed layout I'm trying to use features a page title as part of the nav element.

Because of the strict wall that /app directory layouts have imposed on data traffic from page to layout, I'm stuck with the following options:

1. Give up on having the page title in the nav
2. Make the page title a client component embedded in the server component that pulls the page title either from a context or from a mapping of path -> page.
3. Remove the chrome from the Root Layout and instead add it as a layout on every page individually (and embedded in page.tsx since there's no way to make a nested layout on page that isn't the root layout).

I'll leave a comment on the app directory RFC with what I was expecting, but in general I'm wondering if there's something I've missed about a replacement for getStaticParams or some other way for the page being rendered to send a parameter to the layout as part of the server-side render.

[maltekuehl]

I'm having a similar issue and so far my solution is to call router.refresh() in the client component of the page, this causes the data to be refetched in the background and the layout to be updated as well.

This however has the downside that client state introduced in the time the router.refresh takes will be overwritten (which I thought was not supposed to happen but does).

So it's something like:

// layout.tsx
const getData (id) => { return pageTitle }

const Layout = async (props: { children: React.ReactNode, params: { pageId: string } }) => {
   const pageTitle = await getData(props.params.id)

   return (<><h1>{pageTitle}</h1><div>{children}</div></>)
}

// page.tsx
const Page = async (props: { params: { pageId: string } }) => {
   return (<><div><ClientComponent /></>)
}

// components/ClientComponent.tsx
'use client'
import { useRouter } from 'next/navigation'

const ClientComponent = () => {
   const router = useRouter()
   useEffect(() => { router.refresh() }, [router])

   return (<>Content</>)
}

[maltekuehl]

I'll detail my use case a bit further, in case anyone has any suggestions or knows of an idiomatic way of doing this.

• layout.tsx: Overview of a question session with a short preview of each question for navigation and the current study status (correctly/wrongly answered or still unanswered)
• page.tsx: Contains the client Question component
• Question.tsx: Sends a POST request to /api/question/[id]/answer/ when the question is answered

My problem: I can't find a way to properly keep the study status in the layout overview in sync with the events from the client component.

Possible solutions I have found so far are:

• Integrate everything into the page and lose the advantages of having a layout file
• Using custom window events that a client components inside the layout file listens for. Very clearly not idiomatic Next.js and against the spirit of the framework.
• Call router.refresh() in the client component after the answer. This introduces a lag and only works for the first question. Once I navigate and answer a second question, the client state (e.g. the selected question option) is not preserved when I call router.refresh(). So far the only fix of this issue I have found is calling router.refresh() right after rendering each question as well, to reset the frontend cache hopefully in time before state is introduced by the user.

That client state is lost when calling router.refresh() if the frontend cache contains previous pages to me seems like undesired and perhaps unintended behaviour. Would be interested to learn whether this is on purpose or perhaps a bug.

[maltekuehl]

In the end I wound up using the ClientContext approach (your 2nd one). Based on the app dir playground app this seems to be the idiomatic Next.js way of doing things and works perfectly fine for my use case without any of the caveats the router.refresh() method had. The only real downside imo is that in more complex use cases one can quickly end up with way to many ContextProviders very quickly.

[zackdotcomputer]

I think the goal is that your problem would be solved by changing the Layout to aggressive revalidate, since without that forced revalidation the router doesn't know the layout may need a refresh in addition to the page. (My understanding is that the goal is that the layout is fetched once and then kept on screen and only refetched if needed or it changes.) Of course refetching it on every request would also, then, diminish its usefulness as a layout file rather than as a server component in your page file...

In the end I'd also have bailed to client context probably. Using the app directory for apps that do more complex CRUD manipulation and seems a bit beyond the beta's capabilities at this stage, sadly. At least until the mutation and client side data paradigms can get ironed out from Vercel

[maltekuehl]

I tried that approach but I was unable to keep the state of a timer I have in my layout component that times the whole session, not individual questions. Maybe there is a way to do it, if there is, it's not obvious from the documentation. All my combinations of preventing prefetching, using router.refresh, changing revalidation patterns by force, etc. had always at least some downside.

I'm eagerly waiting to see what the Mutations RFC will look like, until then I'll probably have to stick with client contexts.

[t-harut]

Any updates?

[efroostrf]

Next 13 and 14 update with export const metadata is amazing, but it ruins any ways to build fully custom head of the page. As I tried you can pass <head> only to the root layout.tsx, and you don't have any options to pass data from page to layout component. So, you was fully unable to edit customly, only throught generateMetadata or metadata const. That's so sad, because we don't have much options to edit in it, even with other feature.
One way to build something like custom it's to create it on client side, using useEffect or something like that... but I think it will not work for Google and another robots, that scans pages 🙃

[welschmoor]

You must "simply" fetch the same data inside generateMetadata. According to docs, it will NOT fetch it twice this way. I'd recommend to test it though if you self-host and also test it if you have no-cache header for these calls. I didn't test it, I mention it because I only trust my own "experiments". Our calls are huge, fetching the same call twice would be fatal.

[leerob]

You shouldn't need to pass data – instead, you would call the same function multiple times and use React's cache() function.

You'll notice this pattern in a few places throughout Next.js. For example, calling the same API in the default exported component for a page as well as generateMetadata or generateStaticParams.

• https://nextjs.org/docs/app/building-your-application/data-fetching/fetching#using-react-cache-and-server-only-with-the-preload-pattern
• https://nextjs.org/docs/app/building-your-application/caching#request-memoization

[maltekuehl]

Thanks for the answer. Though the question is not mine, I feel like this doesn't solve the problem the original poster had in cases where the layout.tsx file is located far away from the page.tsx. E.g.:

• /app/layout.tsx - Layout that should contain some page-specific data, e.g., a heading
• /app/blog/[postId]/page.tsx

Here, layout.tsx would not have access to the postId when rendered as a server component and would thus not be able to provide the necessary arguments to a getData call. This would also not be solved by making the path available to the layout, because there might also be a /app/profile/[profileId].tsx route that may have a different getData method but could affect the same page heading element in the layout.

To the best of my knowledge, this can currently only be solved through the use of React contexts or a lot of code duplication. Maybe that's the best way to solve it, but I could still see arguments as to why it may be nice to be able to pass data directly back to the layout during server-side rendering.

It could be something like:

const layout = (...) => {
  const [pageTitle, setPageTitle] = React.useState('Home')

  return (<>
    <h1>{pageTitle}</h1>
    <div>
      <Page setPageTitle={setPageTitle} />
    </div>
  </>)
}

If <Page> represented the props.children.

[leerob]

It's not clear why you're trying to call that same function in the root layout and the deeply nested blog page - what is use case? 🙏

[maltekuehl]

Hi, thanks for the reply. The use case would be any use case where some content in the layout should change based on a specific property of a nested page. The example given by the OP was the content of a page header layout that should contain the title of the current page. The problem that led me to this thread was updating the status of a question in a navbar of all questions based on the current question, current selected answer, etc. All of my use cases can be solved with context providers or custom event listeners, but that requires some extra steps, and other frameworks like Vue.js/Nuxt.js allow two-way data passing using emit, for example. Only in the context of Next.js layouts is it not possible because we do not have a proper page component to which we can pass a function that changes the parent layout, only props.children. Ideally, there would be a way to already modify the layout components during server-side rendering (when the page itself is a server component, e.g., a static blog article that just wants to change some variable in the layout) and another way to modify it based on changes in a client component (e.g., have a useLayout() function that gives any client component access to variables/functions defined by the layout for use in context like the aforementioned question answering app). I hope this makes sense. In my view, this feature is not critical but rather a quality of life upgrade since it would remove the need for context providers for very simple changes, especially when the layout - page relationship is very tight but they do not have access to the same data because they are located at different levels.