Next.js Discord

Discord Forum

Stop inheriting from root layout

Answered
American Sable posted this in #help-forum
Open in Discord
American SableOP
Hey! I want to have a /dashboard route, and that route should have a custom layout.tsx which should NOT inherit from root layout. How can I do that?
Answered by Losti!
you would have:

- layout.tsx
- (dashboard | auth)/
  - /dashboard
    - layout.tsx
    - page.tsx
- (main)/
  - layout.tsx
  - page.tsx
View full answer

68 Replies

Losti!
Answered on: [Handle multiple roles that access the same route](https://nextjs-forum.com/post/1345348506831032360)

Docs: https://nextjs.org/docs/app/building-your-application/routing/route-groups
This is my app directory
I will also have a dashboard route here with a layout.tsx
But the issue is, that layout.tsx inherits from the root layout.tsx (which is under app folder)
@Losti! This is exactly how next.js component hierarchy works.
American SableOP
But the docs page you sent me is about groups
I think that works like (dashboard)/dashboard/admin, (dashboard)/dashboard/user etc.
I only have one dashboard route
Losti!
yes
but
only dashboard is shown in the url segment
it has no side effects
Losti!
you would have:

- layout.tsx
- (dashboard | auth)/
  - /dashboard
    - layout.tsx
    - page.tsx
- (main)/
  - layout.tsx
  - page.tsx
Answer
Losti!
this way you separate all the design from the main pages, they won't affect the dashboard at all.
@Losti! you would have: - layout.tsx - (dashboard | auth)/ - /dashboard - layout.tsx - page.tsx - (main)/ - layout.tsx - page.tsx
American SableOP
But in this case, wouldn't the root layout.tsx affect both?
Losti!
Exactly
That's why you put the logic of the main pages in their layout
in
(main)/layout.tsx <-
and the logic of the dashboard in
(dashboard)/dashboard/layout.tsx
or (auth)
as you prefer
Root layout is used to store logic and global effects of the application, route groups are used to separate logic without the routes coming into a conflict.
American SableOP
Oh, I see now
Losti!
perfect, then everything is solver;)
American SableOP
So something like this?
Losti!
don't forget the root layout in the app directory
@Losti! don't forget the root layout in the app directory
American SableOP
I'm not looking to have a global layout really
Oh actually I probably do for fonts
Losti!
in my root layout i only added styles for the fonts, the rest would be contexts that i need to work throughout the application
as authentication contexts and themes
American SableOP
What's your root layout.tsx?
Mine is giving 404 right now
@American Sable Mine is giving 404 right now
Losti!
next.js needs a layout.tsx in app directory to work
my root layout.tsx
export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
      <html
        lang={"en"}
        suppressHydrationWarning
        suppressContentEditableWarning
      >
        <script async src="//unpkg.com/react-scan/dist/auto.global.js"></script>
        <body
          className={`${playfair_display.variable} ${montserrat.variable} antialiased`}
        >
          <SessionProvider>
            <NextThemeProvider
              attribute={"class"}
              defaultTheme="light"
              enableSystem
              disableTransitionOnChange
            >
              <LazyAnimations>{children}</LazyAnimations>
            </NextThemeProvider>
          </SessionProvider>
          <Analytics />
          <SpeedInsights />
        </body>
      </html>
  );
}
Remember, as i told you, all the designs that are effective for the main pages can be moved to the layout of the route group with the same name, main.
in my case, i do that, i just use root to add global logic
American SableOP
So I've added my global logic to root, which are basically some preloads and fonts in body
I used to have a navbar, {children} and footer in my old setup
How should I handle that in (main) now?
import { Inter, Geist_Mono } from 'next/font/google'
import '../index.css';

const inter = Inter({
  weight: ['400', '500', '600'],
  variable: "--font-inter",
  subsets: ["latin"]
})
const geistMono = Geist_Mono({
  weight: ['400', '700'],
  variable: "--font-geist-mono",
  subsets: ["latin"]
})

function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <head>
        <link rel="preload" href="/images/logo.png" as="image" />
        <link rel="preload" href="/_next/static/css/app/layout.css" as="style" />
      </head>
      <body className={`${inter.variable} ${geistMono.variable} min-h-screen bg-[#0A291E] text-white`}>
        <main>
          {children}
        </main>
      </body>
    </html>
  );
}

export default RootLayout;
This is my root layout.tsx
Losti!
exactly, move to layout.tsx in (main)
@Losti! exactly, move to layout.tsx in (main)
American SableOP
Now that's what confuses me
Do I also use <html> tags there?
Or not, since they are already used in root layout?
@American Sable Or not, since they are already used in root layout?
Losti!
if you already use in root layout you don't have to define again
it's herarchical
i suggest you read about nextjs component architecture ro resolve your doubts
American SableOP
I think I'm getting it now
Losti!
perfect
i suggest you take a look at it, it will help you a lot.
American SableOP
@Losti! they all seem to work now, thank you a lot!
LuisLl
You could technically have two root layouts, each inside each of your (grouping_folders), and each would need to have their own <html> and <body> etc, this will work like if you had 2 different mini apps and only one will be mounted at a time, which is not the best if you wanna preserve your global configs, since the whole document would be refreshed when navigating between routes that are child of the different root layouts. Makes sense?

The best way for most apps is to do what @Losti! said, keep your root layout in as neutral as possible and add the UI and logic inside the nested layouts and pages.
@Losti! I actually forgot about this little part...
LuisLl
The solution you provided is still better for most use cases I would dare to say.
At the end It will depend on the needs of the app, if he needs to have different user experiences, different theming, maybe to force dark mode or light mode with the theme provider, not to provide a theme provider at all (or any kind of provider), to change the font for the entire tree under that layout...
That's why I worded it as two different mini apps.
https://flags-sdk.dev
i think that unless the application is really complex, there was no reason to separate them in such a way, the best option is a monorepo with tho separate next projects (at least that's what i think).
@Losti! i think these kinds of approaches are problematic, with the departure of flags-sdk if you think about it there wouldn't be much reason to use multiple layout roots
LuisLl
But they are not, that's the kind of problem they solve. Imagine you have docs inside your app and you will allow the user to change between dark and light mode for their preferences, and you want to provide a font that's well redeable and comfortable. You'll want this to be on domain.com/docs/** and only there, then you can make two different layouts. Simple and built in
@Losti! i think that unless the application is really complex, there was no reason to separate them in such a way, the best option is a monorepo with tho separate next projects (at least that's what i think).
LuisLl
Yes exacly, that's why I pointed out this:
The solution you provided is still better for most use cases I would dare to say.