Why do nested layouts/pages render before their parent layouts?

[adamlong5]

Imagine I have this simple nested setup in NextJS's app router:

app/
  - layout.tsx (we'll call this "outer layout")
    - /inner
      - layout.tsx (we'll call this "inner layout")
      - page.tsx (we'll call this "inner page")

If you added a simple console log to the two layouts and the inner page, you would expect the order of your logs to show:

• outer layout
• inner layout
• inner page

That would match the waterfall paradigm of React, and the React component tree shown in the Component Hierarchy docs.

However, when I test this logging, I get the reverse:

• inner page
• inner layout
• outer layout

Besides breaking the intuition of React with this order of execution, it also makes it hard to use layouts to do something like check if the user is logged in and redirect them if they're not — I'd assume the parent layout could do that check, and then the inner layout wouldn't have to worry about it, but that's not the case here.

Am I thinking about this in the wrong way?

[adamlong5]

@leerob This might be a good target for education content, unless I'm doing something wrong that is causing this rendering order.

[leerob]

The outer layouts are not re-rendering in this instance – this is part of the design of the App Router. It means you can share state across page transitions, as the UI components in the layout are able to maintain state.

[adamlong5]

@leerob In this case, I'm doing a full page refresh and the console.log's are in the function for each layout and page. Why would those console.logs fire if the layouts aren't re-rendering? Wouldn't they be rendering for the first time on a full page refresh?

[cacosandon]

@adamlong5 did u find out why this happen?

I have groups of permissions (authenticated), (onboarded), (organization), etc. but if someone is not authenticated, the (onboarded) layout is making requests anyway because of the reversed order.

[gregorybolkenstijn]

We have the same issue. I would expect that the code in those nested components is not reached at all, let alone being fired. This is odd behavior, and we have to add all kinds of unnecessary defensive code to prevent the code in child components from firing. This should at least be explained or documented somewhere.

@leerob can you explain what is happening here and how we can prevent child components from firing?

[ajwootto]

I'm running into this problem when trying to set up a shared server context using AsyncLocalStorage

I assumed that setting up a new storage context in the layout would make it visible to the page below it since it would be calling the Page's render function after the Layout's in the same callstack, but it seems like the page is called first and then the layout. That is really unexpected and should be documented, plus I can't find any other way to have an application-level "context" on the serverside that gets set up and run before all pages

[eseQ]

@adamlong5, @ajwootto How is it going? Did you find any solution, guys? I am totally agree this thing is frustrating and that prevents to implement any auth logic using layouts.
For example:

1. We have auth logic that included different flows:

const async function getAuthData() {
  const isAuth = await auth();
  if (isAuth) {
    await doAuthLogic();
  } else {
   await doTempUserLogic();
  }
}

2. also we have additional fetching for project info projectFetch()
3. We have project pages who shares those logics: app/project/onePage and app/project/anotherPage

What? Do I have to share the logic with pages? Ok:

//app/project/onePage
const user = await getAuthData();
await projectFetch();

//app/project/anotherPage
const user = await getAuthData();
await projectFetch();

That looks good! (nope) But we have layout with user info. Ok, we has got user object in pages, lets pass it to layout. Ooops, it isn't possible. Hmmm, may async_storage is the key? Nope. There is no way to pass any object to layout. We must run this code one more time. Isn't that a problem?

//app/project/layout
const user = await getAuthData();
await projectFetch();

We must run the code every time we want to get the information related to our auth/project logic. THIS IS THE PROBLEM. But why is it doing this way? And, more importantly, how do we deal with it?

[eseQ]

TL;DR;
We have:

• Root layout (L0) with user info panel
• Nested layout (projects for example) (L1) with project widget
• Page (for example: projects/page) (P2) with project info

<L0>
  <L1>
    <P2 />
  </L1>
</L0>

Expected behaviour:
render L0: get authorization, pass auth data next to tree
render L1: auth is available, get project data, pass project data
render P2: auth is available, project data is available

Current behaviour:
render P2: get authorization, get project data
render L1: get project data again, pass to project widget
render L0: get authorization again, pass to user info panel

[ajwootto]

@eseQ the way I solved it for our case was to basically call the code that represents the "shared data" more than once, but to use React.cache for request-level caching. In your case I think you could have a getProjectInfo method somewhere that is wrapped in cache, thus all the components that need that data can safely call the method but it will only run once per request:

https://react.dev/reference/react/cache

[eseQ]

@ajwootto yep, i did this way but it is still not the best design

[zhm]

@ajwootto how about server actions? It seems React.cache does not work the same from a server action. I'm looking for a similar solution to "request-local context" that works in both server components and actions.

[mp3por]

Soooo ? Is this by design and will never be fixed or this is a bug ? I am having the same issue.

I used the layouts to "guard" against auth/not-auth users. I have AuthLayout -> OffersLayout -> OffersListPage/OffersMapPage. In the AuthLayout I get the user and redirect to login if there is no auth. In the OffersLayout I setup common controls for the Map/List pages like Search. In the Map/List page I show the offers in different ways. At the moment due to this bug I can not rely that the user is there.

Please respond.

[Chelvis]

Yes... almost one year later and here we are. Having issues with the same b̶u̶g̶ feature here. I update things in the DB from the layout.tsx file and I need those updated things in the page.tsx file, but page fetches the data before layout changes them. Anooooying.

[aprilmintacpineda]

I'm currently experiencing this for my app, trying to force users to go through onboarding and the way I think would be best to do that is by checking the user's onboarding progress on the layout page, I have a similar code below:

export default async function LoggedInUserLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  const user = await getUser();

  if (!user.onboardingCompleted)
    return <Onboarding />;

  return (
    <>
      <TopNav>
      {children}
    </>
  );
}

I think the only way to actually achieve this currently is by using HOC (higher order component) pattern which is pretty ugly.

So basically:

src/hoc/with-auth-guard.tsx

export interface PageArgs {
  params: { slug?: string };
  searchParams: Record<string, string | undefined>;
}

export interface AuthProps {
  user: User;
}

export default function withAuthGuard(
  Component: React.FunctionComponent<AuthProps & PageProps>,
) {
  return async (args: PageArgs) => {
    const user = await getUser();
    if (!user) return redirect('/sign-in');

    if (!user.onboardingCompleted)
      return redirect('/onboarding');

    return (
      <Component
        user={user}
        {...args}
      />
    );
  };
}

Then on ALL your pages (and this is the annoying part because now you have to use this to all your pages otherwise it won't work as intended and all children component logic will still get executed)

src/(auth-screens)/dashboard

function DashboardPage () {
  // your logic here
  return <Something />
}

export default withAuthGuard(DashboardPage)

The reason why this problem occurs is because of how function calls work in the first place, React components are basically just functions that return html, and JSX is actually compiled into regular function calls, so:

<Component1>
  <Component2>
    <Component3>
      <h1>hello world</h1>
    </Component3>
  </Component2>
</Component1>

Is actually compiled into something like this

Component1(
  Component2(
    Component3(
      'h1'
    )
  )
)

and of course, by way of execution, the inner most function gets executed first and the return is passed into the function call above that, and so on.

The problem stems from how we accept the children in the layout, we accept it as a ReactNode rather than a ReactComponent therefore, the moment the layout receives it, it has been executed! NextJS can improve this in 2 ways

1. Pass ReactComponent rather than ReactNode in the layout component and the layout component will be responsible for rendering it like so: <PageComponent />.
2. Introduce the concept of route level middlewares or route guards which will be executed first and can do various things like redirect the user to another page, write to cookies, etc -- perhaps even return a component on this level?

[jetaggart]

I have this exact same problem, Did anyone figure out a solution to this? We have a layout that's protecting certain pages if they need to be fully onboarding "OnboardingBoundary". What I expect is I can redirect server side if I detect they're not fully onboarded, however every page is throwing errors because the nested page is not in the correct state to render (they are not onboarded). How would I deal with this?

For example our onboarding boundary that's in our layout:

export default async function OnboardingBoundary({
  children,
}: {
  children: React.ReactNode
}) {
  const status = await gateway.onboarding.status.get()

  if (status.onboarding.currentStep !== OnboardingStatusComplete) {
    redirect("/onboarding")
  }

  return <>{children}</>
}

I'd expect this to protect pages that are nested under it (any child) since that's how react renders. However the exact opposite happens our app is puking errors since nested pages assume they're onboarded, and if they aren't I wouldn't expect those pages to render.

What is the solution here? Seems like a huge reversal in the mental model of how react works.

I feel like this could be accomplished with middleware but feels insane and fragile to map all our routes out that need protecting in a middleware file... given react handles this via optional child rendering.

[teremy]

I am experiencing a similar issue. I am doing some configuration in layout.tsx, for example for my axios instance, that is used in a page.tsx, but page.tsx is called before layout.tsx. Is there any file that is called before page.tsx, where I can put global configuration?

I also found a similar issue:
#62574

and I created my own:
#67450

[maxijonson]

Closest workaround I got is the HOC solution proposed by aprilmintacpineda (which is like a throwback to the class components era 😅 ). However, in my specific case, this just renders the layout.tsx useless.

In my case, we wanted a set of pages that are only available on non-production builds. We expected layout.tsx to act like a guard for all other pages in the (exclude-prod) folder (and its sub-folders). Even though the end-result is a 404 Not Found page (as expected), since the page.tsx file still runs server-side code, it attempts to do things not available in production environments, which crashes our build.

// (exclude-prod)/layout.tsx

const ExcludeProdLayout = ({ children }) => {
  if (process.env.NEXT_PUBLIC_VERCEL_ENV === "production") {
    notFound();
  }
  return children;
};

// (exclude-prod)/test-page/page.tsx
const TestPage = async () => {
   await doSomeNonProductionOnlyWork(); // Crashes production builds
}

Without an HOC, we need to simply duplicate the logic in all of our test pages, but then the layout.tsx file is useless.

// (exclude-prod)/test-page/page.tsx
const TestPage = async () => {
  if (process.env.NEXT_PUBLIC_VERCEL_ENV === "production") {
    notFound();
  }
   await doSomeNonProductionOnlyWork();
}

[AAAboutajedyne]

It's a design choice. I had same issues, cause intuitively I put my shared fetching and logic at layout server component but the doc says:
"By default, layout and page segments are rendered in parallel. This means requests will be initiated in parallel." excerpt from the doc.