What's the best way to handle a complex layout of multiple routes? (details inside)
Unanswered
Boreal Chickadee posted this in #help-forum
Boreal ChickadeeOP
I have a pretty complex layout with multiple routes and shared contexts. I tried two different setups.
setup a) one big page
the downside here is that the entire layout re-renders on every route change, and scroll positions are not maintained
setup b) individual layouts for each route
the downside here is its far more complex – and lower layouts can't access nested params (like the first column accessing the current year param). this also involves me adding in nested layouts and skeleton pages which has its own problems.
setup a) one big page
the downside here is that the entire layout re-renders on every route change, and scroll positions are not maintained
setup b) individual layouts for each route
the downside here is its far more complex – and lower layouts can't access nested params (like the first column accessing the current year param). this also involves me adding in nested layouts and skeleton pages which has its own problems.
15 Replies
Boreal ChickadeeOP
sorry my second layout was wrong, added it below
Boreal ChickadeeOP
some additional info: everything here is read only and can be cached infinitely – there are no mutations or user auth, which greatly simplifies the data/loading architecture
European sprat
if it's all static data can't you use this:
https://nextjs.org/docs/app/api-reference/functions/generate-static-params
https://nextjs.org/docs/app/api-reference/functions/generate-static-params
Boreal ChickadeeOP
well its not all static at build time (new data can be added) – but for the life of the user session, static is ok
I could rebuild once a day
@European sprat if it's all static data can't you use this:
https://nextjs.org/docs/app/api-reference/functions/generate-static-params
Boreal ChickadeeOP
does this let me access nested params inside a lower level layout?
that looks like it
i've never used it and don't know if it will work for your use case but it's something that came to mind that might be worth looking at for you
Boreal ChickadeeOP
yeah maybe – also worth noting that there are millions upon millions of routes so I don't know how that would affect the build runtime or memory/storage
thanks for the URL
European sprat
ah ok then it may not be the best to use but if there's a known group of commonly accessed routes then it can still be useful and you could limit the static generation to just those routes and keep it dynamic for the rest
Boreal ChickadeeOP
looks like the best way for me is just to turn things into client components and use
const year = useSelectedLayoutSegment();Boreal ChickadeeOP
I think that's the best solution here