Next.js Discord

Discord Forum

Downside to root layout using "use client"?

Unanswered
Lithuanian Hound posted this in #help-forum
Open in Discord
Lithuanian HoundOP
I'm in a bit of a stuck situation. What I'm ultimately trying to do is have it so on my landing page, my header and body have certain css properties set, and on all other pages, a different set of values (I'm doing a larger header on my landing, smaller once in the site). I found if I use the next-url header, it treats 404 pages as my landing, thus messing up the header size. So I tried making a route group instead, having one layout for my root page and another for the rest, but this means I have to repeat that layout among my root, not found, and loading pages, creating a lot of repetition, and the worrying concern that because of the loading, my header and footer are going to basically be rerendering on every page load. The final thought i was lead to was to use usePathname on the root layout, but that would require using use client. If my understanding is correct, that would lead to all children of the root layout, thus everything, first being loaded staticly, then rehydrated, and if they're not actually user interactive, it would mean a lot of lost performance, right? I'm just stuck on what I should do. This doesn't feel like an unusual thing to do, but I'm not getting how I should do it.

69 Replies

Arinji
useClient isnt bad, since its prerendered like server components you wont see perf drops
its recomendded to keep it server since ideally you fetch data in the layout + you can directly import server components and client components in it
@Lithuanian Hound
Lithuanian HoundOP
Ok.
I want to keep it server, but I can't seem to figure out how to figure out if it's the root page or not. next-url returns null or / (depending on a trailing slash) if I hit a non-existent page. usePathname gives me the proper response, but that requires it to be a client page.
We don't have access to the request object, which is completely insane to me from a server rendered app, so I just feel like I'm stuck.
Every option seems like a programming anti-pattern... repeat code, make everything client, etc...
Sorry, I've been trying to figure out a solution to what I expected to be one of the easiest parts of my site for 4 hours
Arinji
well why do you need the request object? if you let me know i can tell you where to access
Lithuanian HoundOP
My end goal is is my root layout to know if it's on my landing page or not. If it is the landing page, use css a, if not, use css b.
Lithuanian HoundOP
On my landing page, I want to make the header bigger, affecting the top margin of my main section, and on every other page, I want it to be the "standard" size.
Lithuanian HoundOP
Well, the header and main, which I would consider as the layout components, but on the / url
Arinji
got it
ok so basically, leave layout as server
make a client wrapper
wait one sec
just to check

if user is on the landing page.. make the header bigger?
i feel like im missing something here
Lithuanian HoundOP
Nope, that's it. I don't know what I'm not getting/missing that's making this so hard.
My root layout is basically:
        <html lang="en">
            <body
                className={`bg-body-black ${open_sans.className} ${agency_fb.variable}`}
            >
                <Header tallHeader={tallHeader} />
                <main className={classes}>{children}</main>
                <Footer />
            </body>
        </html>
really, everything should be under children
But when it's on the / page, I want to basically pass true to tallHeader
That's it
Arinji
OH i get it now
make Header a client component
and usePathname in there
Lithuanian HoundOP
Sorry, one part missing
Arinji
keep layout as a server component, its easier that way'
Lithuanian HoundOP
Main also needs certain classes
Header already is a client component for other reasons :p
Arinji
ok so make a client wrapper, put both the header and main in there
usePathname inside there
and call the client wrapper, instead of main and header
Lithuanian HoundOP
Ok, I guess so
That won't make all children of main client components?
@Lithuanian Hound That won't make all children of main client components?
Arinji
nope, one sec there is a good blog addressing that by nextjs.. lemme send
Lithuanian HoundOP
I appreciate it
This feels like such a weird paradigm to follow that would easily be resolve by access to the request that the server already has :p
Arinji
ok i cant find it rn, but basically it wont
so how it works is, when you do {children} nextjs wont change the children
Lithuanian HoundOP
Got it
Arinji
hence why client components cant just import server components, but they can wrap server components and use {children}
Lithuanian HoundOP
Ok, makes sense
@Arinji No worries, if you need request access..use middleware
Lithuanian HoundOP
Honestly, my next step was going to be creating a context, having the middleware save the request object to the context, thus making it globally available.
I'm a BE engineer, and not having access to the request on a server side app is so strange
Arinji
thing is, you can use most of the request object like cookies and headers
Lithuanian HoundOP
Yah, I saw that
And exactly that discussion!
Heh
And most is nice, but not all is strange
Arinji
i have a lot of discussions subscribed lol
Lithuanian HoundOP
Like having direct access to the requested path
Rather than just the next-url
Which is a modified value
And yes, we can do it via header data
Which requires parsing
Which the request object has already done
It's just weird to see so many posts/updates go towards the server side functionality of nextjs, then hear "we're not giving you access to the request object, a feature most server side frameworks have"
I'm ranting now, sorry
It's just frustrating
Even this solution feels circuitous
Lithuanian HoundOP
Yup, saw that :/