params for layouts should include ALL dynamic route parameters, regardless of depth in the tree

[chrishyle]

Describe the feature you'd like to request

Currently, a layout component only receives params for the route segments "from the root segment down to that layout". However, there are many common patterns where a higher-level layout may need to know all of the dynamic segments, for example, breadcrumb links in a global header or footer. The Vercel web app is a good example: it uses a global top-bar with breadcrumb-like links that update as the user drills down into their deployments.

Ex:

-------(Global header)-----------------------------
My app > Some Group > Some Sub-group > Some thing > …
----------------------------------------------------

This would be simple to do if the root-level layout were given all of the dynamic route params, but is (maybe?) impossible to do without it.

Describe the solution you'd like

All layout components should receive the complete set of params for the route being rendered, regardless of where they are in the file tree.

Today, when rendering /[groupId]/[itemId]:

File	Params
app/layout.js	{}
app/[groupId]/layout.js	{ groupId: "…" }
app/[groupId]/[itemId]/layout.js	{ groupId: "…", itemId: "…" }

Proposed, when rendering /[groupId]/[itemId]:

File	Params
app/layout.js	{ groupId: "…", itemId: "…" }
app/[groupId]/layout.js	{ groupId: "…", itemId: "…" }
app/[groupId]/[itemId]/layout.js	{ groupId: "…", itemId: "…" }

I suspect this may de-optimize some caching or streaming being done for layouts, as the higher-level layouts would now need to be re-computed more often, but the alternative (described below) is that a developer will have to forego the nested layouts anyways. Perhaps it can be opted in to?

Describe alternatives you've considered

In order to do breadcrumb links (and other common nav patterns that rely on the full route) in layouts right now, you have to NOT use nested layouts, and instead provide redundant layout files at all of the leaf-nodes of your file tree, or skip layouts altogether and just render pages with redundant global components.

[verekia]

I am also facing this issue in the context of a multi-language website, where most of the content is available under a [lang] segment, but I also have a root-level page that defaults to English:

example.com/
example.com/en/something
example.com/fr/something

Ideally you'd want a single layout in this situation:

[lang]
  something/
    page.tsx
page.tsx
layout.tsx

and the root layout can display UI elements in the appropriate language.

But because params.lang is empty when visiting example.com/, I cannot default to English.

I had to do this kind of workaround:

[lang]
  something/
    page.tsx
  layout.tsx    <= uses <MainLayout>{children}</MainLayout>
page.tsx        <= uses <MainLayout><HomePage /></MainLayout>
layout.tsx      <= this is empty, <>{children}</>
MainLayout.tsx

But this is bad because MainLayout.tsx remounts completely when going from example.com/ to example.com/en/something, which breaks my animated navigation transition.

[verekia]

I was able to solve my problem with the following structure:

(en)
  page.tsx
  layout.tsx      <= uses <MainLayout lang="en">{children}</MainLayout>
[lang]
  something/
    page.tsx
    layout.tsx    <= uses <MainLayout lang={params.lang}>{children}</MainLayout>
MainLayout.tsx

[NikitaIT]

this still causes the layout to re-render

but it's possible to do this:

(index)
  page.tsx
  layout.tsx      <= uses <MainLayout lang="en">{children}</MainLayout>
[lang]
  something/
    page.tsx
    layout.tsx    <= uses <MainLayout lang={params.lang}>{children}</MainLayout>
layout.tsx    <= shared layout
MainLayout.tsx

 "/" => layout.tsx + (index)/layout.tsx + (index)/page.tsx
 "/en/something" => layout.tsx + [lang]/something/layout.tsx + [lang]/something/page.tsx

[pksorensen]

I also think params should be there on all levels, right now one have to parse urls manually to get the params at a higher level layout. Lets say i want to build breadcrums i am missing this info

[leo-cheron]

Even if a layout is not meant to be rerendered, this seems important to have access to all params in any layout if any initial component rendering depends on a child param.

We have currently no workaround to deal with this server side without accessing headers (which would make the layout dynamic and slow).

[jacobdubail]

How do folks build breadcrumbs in a layout at the top level if there are multiple layers of dynamic routes?

[jayenashar]

the names won't appear in the SSR this way.

i'm currently working on doing it in middleware.

[ADTC]

I don't understand. If you want it in SSR then do it in a server component. And pass it as prop to client components. You can use await in server components.

[jayenashar]

layout as a server component doesn't have access to ALL dynamic route parameters, regardless of depth in the tree.

[ADTC]

@jayenashar so I get what you mean now. Yes, currently it doesn't have all the dynamic route parameters. That's why you'll have to resort to one of the many workarounds discussed here, or use a client component to async retrieve that data and render the component on client (no SSR).

I suppose middleware is one way, as you can inject it in the headers somehow. I think it was discussed here somewhere. Good luck!

[jayenashar]

i saw it in another discussion. i injected it into a cookie and it's working fine. i couldn't use the node.js APIs in the middleware so i did a fetch() to localhost:${PORT} and called a route handler.

my next issue is that server components are being rendered during navigation for a server function request instead of the target navigated page request. it only happens in production.

[ADTC]

The pattern I'm using is to have a client component inside layout which changes based on useParams and/or usePathname. We still get the benefits of server-rendered layout for the rest of the layout, but just for that dynamic part which changes based on route changes, it's a client component which will re-render based on param changes or path changes.

layout.js (or layout.tsx)
   Server Component <-- this renders only once
      server-rendered stuff
      Client Component <-- this re-renders when route changes
      server-rendered stuff

The unfortunate consequence of this is that I would have to do API calls in the client component to gather necessary data (which I do using server actions), and I cannot pre-fetch those data in the server component (or layout.js) and pass it down to client as props. The latter is preferred, but only possible in pages or nested layouts (with access to params).

If you do use Server Actions to abstract your API calls, then you can write an action that returns the bare minimum data needed instead of all the data from backend.

[marcoripa96]

I ended up exactly in this situation. I wanted to implement the Vercel toolbar and ended up trying a very counterintuitive (maybe not a good documented behaviour) using parallel routes. I wrote a tweet about it and exactly like 20 minutes later, someone from Vercel actually tried the same thing with a solution on the same path.

The idea is to use parallel routes and only render a breadcrumb on the desired segment. My initial solution wasn't great, you can read about the idea here: https://twitter.com/mrcrp96/status/1789055528104063162

And you can see a full example of the implementation here:
https://github.com/agadzik/parallel-routes-breadcrumbs

Overall it's a bit too complex I think, and having all descendants params in the parent layout would be great to achieve this behavior in an easier way

[ADTC]

Unbelievable that Vercel's own breadcrumbs toolbar is hard to replicate in Vercel's own Next.js framework.

Is your full example the solution from Vercel? Or it's your initial attempt?

[marcoripa96]

The full example is from a Vercel engineer. You can read more about it here: https://twitter.com/z0oks/status/1789057536282227092. The example was linked after I asked for it in the replies.

[renenielsendk]

I have been spending so much time implementing a layout breadcrumb also.
ONLY because i can't access dynamic route params from the layout.

So +1 for this

[ADTC]

So now the problem we encounter with my brilliant solution, is that when you change something in backend, it wouldn't immediately reflect in the breadcrumbs even if you call router.refresh(), because the useEffect hook to fetch the data wouldn't run unless the param changed.

I so wish Next.js would add a new prop to Layouts called allParams or pageParams which would just give the entire list (The dynamic route parameters object from the root segment down to the page rendering that layout.) and save us all the trouble of dealing with this 💩 and the complex workaround solutions involving parallel routes.

[Ronnin1994]

Well, still no changes on this issue. Have the same issue where I need to access a params in my top level layout.

[conoremclaughlin]

We're also struggling with this. +1 to making access to search params in the layout opt in. Those that opt out can receive the optimizations and those that don't, don't need to create page wrappers and proxy params to capture this server-side functionality.

[nxl3477]

Let me share my implementation method

[lang]
-something/
--page.tsx
--layout.tsx
page.tsx
layout.tsx <= uses <LayoutClient><head>.....</head><body>{children}</body></LayoutClient>
layout.client.tsx <=

 'use client'  
 const segments = useSelectedLayoutSegments() 
 // do something 
 return (
     <html lang={lng} dir={dir(lng)}>{children}</html>
 )

[petr-like]

if u do set use client for root layout, u cant then use async/await methods at children's components

[LeulAria]

i mean layout should be some kinda middleware for it's nested childs thus it should have all the query state ? any solution here ?

[azizoid]

I double this problem. layout should have access to all the possible parameters

[andreasnett]

Just came across this problem and was able to solve it using a Client Component inside the layout. The Client Component will update its usePathname() on navigation, but not cause blips on the screen.