What is the guidance for deeply nested search param usage in RSCs?
Unanswered
Spot-breasted Oriole posted this in #help-forum
Spot-breasted OrioleOP
I feel like i’ve seen different flavors of this question, but wanted to ask it more directly.
For pages where you know they’re driven by search params and need those params in deeply nested server components… what is the recommended approach?
I’ve seen an array of suggestions like
1. Suck it up and prop drill
2. pass them as headers in middleware
3. use client components
4. Use something like nuqs or similar data store scoped to a request with React.cache to pull them safely
5. “skill issue stop using search params”
Totally get that search params opt you into dynamic rendering and there are opportunities with PPR. But working in a monorepo with a lot of components, some of which are deeply nested on searchParam different pages has shown some challenges when it comes to figuring out how best to access this data in RSCs.
Thanks for any thoughts.
For pages where you know they’re driven by search params and need those params in deeply nested server components… what is the recommended approach?
I’ve seen an array of suggestions like
1. Suck it up and prop drill
2. pass them as headers in middleware
3. use client components
4. Use something like nuqs or similar data store scoped to a request with React.cache to pull them safely
5. “skill issue stop using search params”
Totally get that search params opt you into dynamic rendering and there are opportunities with PPR. But working in a monorepo with a lot of components, some of which are deeply nested on searchParam different pages has shown some challenges when it comes to figuring out how best to access this data in RSCs.
Thanks for any thoughts.
3 Replies
Spot-breasted OrioleOP
My example use case is a page that can be nearly entirely rendered in server components, all data fetching can happen there too.
But there’s a single fairly dynamic form component with many options that drives how the page renders based on pushing to searchParams.
The form doesn’t mutate anything, it’s more like applying filters to a search.
But there’s a single fairly dynamic form component with many options that drives how the page renders based on pushing to searchParams.
The form doesn’t mutate anything, it’s more like applying filters to a search.
nuqs is a good library
Spot-breasted OrioleOP
ya I like nuqs, just looking for more official guidance one way or another
I get the sense there’s an intention behind only making searchParams available from the page interface, but maybe it’s only to prevent people from shooting themselves in the foot
I get the sense there’s an intention behind only making searchParams available from the page interface, but maybe it’s only to prevent people from shooting themselves in the foot