[Next 13] Server Component + Layout.tsx - Can't access the URL / Pathname

[adileo]

Edit: Please see the response and solutions here: #43704 (comment)

[adileo]

Related comment:
#41745

[Fredkiss3]

Since layouts can wrap multiple routes and don’t rerender on route changes, it cannot take these arguments as props.
for the use cases you are looking for, NextJs. Provides some hooks that you can use inside children client components in the layout.

If you want to highlight a selected link, you can use useSelectedLayoutSegment, in the docs : https://beta.nextjs.org/docs/api-reference/use-selected-layout-segment

The useSelectedLayoutSegment hook allows you to read the active route segment one level down from a layout. It is useful for navigation UI such as tabs that change style depending on which segment is active

to get the params, you would have to use it either in the page.tsx server component, or by using usePathname inside a child client component of the Layout.

The question about the utility of a layout, I see this file as for ex a component that wraps your dashboard and first check if you are logged in, (with cookies and all) and can redirect to login if it is the case. As well as provide a shell witch contain a sidebar (for ex), and that sidebar is client component which uses useSelectedLayoutSegment to determine which link should be highlighted.

[adileo]

Thanks a lot for you Answer @Fredkiss3
At the end I resorted to do something like you described but wasn't very sure on the approach. Now at least I'm sure it's the only way to go.

The question about the utility of a layout, I see this file as for ex a component that wraps your dashboard and first check if you are logged in, (with cookies and all) and can redirect to login if it is the case. As well as provide a shell witch contain a sidebar (for ex), and that sidebar is client component which uses useSelectedLayoutSegment to determine which link should be highlighted.

In this specific case I think neither Layouts are useful, for example if you want to redirect the user to the login page and you want to preserve the previously accessed URL, to redirect the user back once logged id, you can't do that, since you can't access the current page URL.
At the end I resorted to "middleware.tsx" in order to do that.

At this point I'm thinking layouts just as dummy "html" wrappers easily replaceable by a page.tsx splitted with different components. The benefits of not having to reload/re-render the layout seems trivial against the limitations/boilerplate needed to make them work. But open to change idea on that :)

[Fredkiss3]

The thing is that if you use a page.tsx with multiple component (like a Layout component that wraps your entire page), with each page navigation you have (1) a rerender, (2) you loose the benefit of nested layouts since your page will need to have logic for each level of nesting. Instead of that you could delegate the basic layout of your page to a higher layout component and simplify your page logic, which will contains only the logic for the concerned page.

With a page component of a blog with a sidebar with all articles you have :

 // app/blog/[slug]/page.tsx

export default async function ArticlePage({params}) {
  const sidebarArticles = await getAllArticlesForSidebar();
  const currentArticle = await getArticle(params.slug);

  return  (
    <RootLayout>
          <BlogLayout sidebarArticles={sidebarArticles}>
             <article>
                {/* page content ... */}
             </article>
          </BlogLayout>
    </RootLayout>
}

But with layouts, you can put the logic of the sidebar up in the hierarchy :

 // app/blog/[slug]/page.tsx

export default async function ArticlePage({params}) {
  const currentArticle = await getArticle(params.slug);

  return  (
    <article>
       {/* page content ... */}
    </article>
}

 // app/blog/layout.tsx

export default async function BlogLayout({children}) {
  const sidebarArticles = await getAllArticlesForSidebar();

  return  (
     <main>
            <SideBar articles={sidebarArticles} />
            {/* this will be the content of your ArticlePage component for ex. */}
            {children} 
     </main>
}

// app/layout.tsx

export default async function RootLayout({children}) {
  return  (
     <html>
            <head>
               <link rel="icon" href="/favicon.svg" />
                <meta name="viewport" content="width=device-width" />
           </head>
            <body>
              {children}
           </body> 
     </main>
}

The Layout will be used by every child of the layout which wraps them and you could nest as many layouts as you need.
One other benefit is that, on the server when navigating inside a layout, only the data needed for the children will be refetched (unless forced), but with the first approach, each time you navigate to another route, you have to make multiple requests to fetch your data.

[jleclanche]

It's extremely counter-intuitive that there's basically no way to get the pathName from a server-side component. usePathname should at the very least be callable from the server-side as well even if it hits a different code path.

[eric-burel]

I've been exploring Next.js codebase for an article about server context. In order to get access to more request information than headers and cookies, as far as I understand, a small modification would be needed in Next.js code so that the underlying AsyncLocalStorage includes the request URL in addition to cookies and headers. This way you could create a "url()" function.
See this file: https://github.com/vercel/next.js/blob/canary/packages/next/src/server/run-with-request-async-storage.ts
Edit: up to date file: https://github.com/vercel/next.js/blob/canary/packages/next/src/server/async-storage/request-async-storage-wrapper.ts

Not sure how this would interact with layouts, that's the generic logic that populates the "cookies()" and "headers()" functions basically

I am not sure why this function haven't been implemented yet, maybe there is a good reason for that

[pauliusuza]

We would like to access the current url / path as is in the Layout in order to set specific css variables on the body element

[irfanullahjan]

At least for the redirect() e.g. when a user is not logged in, a workaround would be to place it in the layout.js of each "top-level" route segment. It worked nicely for me.

To redirect to login:

// app/some-private-segment/layout.js

import { redirect } from "next/navigation";
import { myFetchWrapper } from "../../utils/myFetchWrapper";

export default async function PrivateLayout(props: any) {
  const user = await myFetchWrapper("/auth/current-user");
  if (!user?.userId) {
    redirect("/user/login");
  }
  // ...
}

To redirect away from login and signup pages

// app/user/layout.js

import { redirect } from "next/navigation";
import { myFetchWrapper } from "../../utils/myFetchWrapper";

export default async function LoginSignupLayout(props: any) {
  const user = await myFetchWrapper("/auth/current-user");
  if (user?.userId) {
    redirect("/");
  }
  // ...
}

Back to the original question: the idea of URL and the request object gets a bit confusing due to nested layouts. When the user navigates between pages deeply nested, the higher-level layouts don't necessarily get recomputed (as far as I understand) and all that caching behavior makes this even more difficult to understand what really goes on during a request. But still, maybe some of the request context could be passed as read-only to the server components as props.

We also have the option to use a middleware for this anyway.

[karlhorky]

I'm also coming here trying to access searchParams from a layout in order to do /login redirection.

Why not Middlewares? I guess often Next.js Middlewares are suggested as a solution for auth redirection, but middlewares don't currently support a Node.js runtime, so they are not useful for cases such as querying a database directly.

Another way of performing a /login redirect using searchParams with lack of props passed to Layout is to:

1. Duplicate your logic for detecting a necessary redirect from login/page.tsx to login/layout.tsx
2. If your logic in login/layout.tsx detects that a redirect is necessary, only return props.children in the Layout and handle the redirect from login/page.tsx

For example:

// login/layout.tsx
import { cookies } from 'next/headers';

export default async function AuthLayout({ children }: { children: React.ReactNode }) {
  const sessionToken = cookies().get('sessionToken')?.value;

  if (sessionToken) {
    // Avoid rendering layout if user already logged in
    if (await getUserByToken(sessionToken)) return children;
  }

This return children will cause the page to be rendered, which in turn will redirect the user based on the ?returnTo= value in the search parameters:

// login/page.tsx
import { cookies } from 'next/headers';

export default async function LoginPage({
  searchParams,
}: {
  searchParams: { [key: string]: string | string[] | undefined };
}) {
  const sessionToken = cookies().get('sessionToken')?.value;

  if (sessionToken) {
    // Redirect to `returnTo` search param if user already logged in
    if (await getUserByToken(sessionToken)) {
      redirect(searchParams.returnTo || '/');
    }

    // If a user is not found, delete the invalid session token
    cookies().delete('sessionToken');
  }

[karlhorky]

@adileo would you be open to editing this issue to add some further details? For example:

1. Editing your title + description of this PR to also explicitly mention searchParams? The pathname by itself wouldn't contain that
2. Adding a StackBlitz demo - @mpereira created a nice demo in RootLayout doesn't receive searchParams as props #43863 which could possibly be used as a starting point

After these changes I think it's possible to close #43863 as a duplicate...

[pauliusuza]

For anyone looking for a workaround of accessing current url on the serverside layout (appDir: true), here's how we did it using a middleware:

// /middleware.ts
import { NextResponse } from 'next/server';

export function middleware(request: Request) {

  // Store current request url in a custom header, which you can read later
  const requestHeaders = new Headers(request.headers);
  requestHeaders.set('x-url', request.url);

  return NextResponse.next({
    request: {
      // Apply new request headers
      headers: requestHeaders,
    }
  });
}

Then use it from inside of a root layout:

// /app/layout.tsx
import { headers } from 'next/headers';

export default function RootLayout() {
  const headersList = headers();
  // read the custom x-url header
  const header_url = headersList.get('x-url') || "";
}

[y-nk]

I've been trying @pauliusuza workaround which worked seamlessly BUT have spent a day to discover that it'd disable SSG. if you put headers in your root layout, there's not a single page which will be able to SSG ever ⚠️

Full explanation here:

#41745 (comment)

TLDR: