searchParams on the Page context vs useSearchParams

[devjiwonchoi]

IMO the searchParams that is being passed down to the Page component as the context is a successor to the useSearchParams hook.

What would be the use cases that useSearchParams are preferred over the context searchParams?

Reference

• searchParams
• useSearchparams

[laugharn]

searchParams is not available on static generation.

[devjiwonchoi]

Yeah, but my question is what are the use cases that useSearchParams are preferred over searchParams?

[eric-burel]

It will keep the page static while searchParams will trigger per-request server-side rendering.

[prkagrawal]

1. When we need to use search parameters in components or layouts,

• pass searchParams prop
• useSearchParams hook (rerenders with latest search parameters)

2. Static rendering

3. Access to URLSearchParams interface, searchParams only returns a simple object

[eric-burel]

@devjiwonchoi searchParams from page props will trigger dynamic (server-side, request time) rendering.
useSearchParams will keep the page static, but will use client-side rendering.

You can't have server-side static rendering and searchParams without client-side rendering (you can have static + client-side though) because they are not part of "generateStaticParams", sadly.

[franky47]

@eric-burel side question: is there a way to access the page props searchParams in a deeply nested server component?

Since Context is not available on the server and ServerContexts don't have consumers, it seems like prop drilling is the only option. 🫤

[eric-burel]

@franky47 cache is the equivalent to client-side context, check my article about that (note: the naming "server context" is an unfortunate choice of mine, I wrote the article before this feature was really documented and serverContext in Next/React is actually smth else, meant to share data between server and client) or this SO post.

Edit: also I've crafted an open source demo here

Code would look like this:

// ctx.ts
import { cache } from "react";

export const getServerCache: () => { preview: boolean } = cache(() => ({
    preview: false
}))
...
// In your page
const ctx = getServerCache()
ctx.preview = !!searchParams.get("preview")
...
// in a component
const ctx = getServerCache()
if (ctx.preview) ...

Note: you might want to give it a shot I haven't used this pattern ever since I don't have this level of nesting.

[franky47]

I figured the cache was the way to go, but having not slept much last night, the solution wasn't immediate, thanks for this pointer! It didn't occur to me to mutate the cached object, but since only the object ref is cached, it makes sense.

I'm trying to provide an automated abstraction for next-usequerystate to feed it all the searchParams, have them parsed at the page top level, and access them as needed in server components.

Making it all type safe is going to be fun! 😊

[elijaholmos]

I'm curious if any of the above answers have changed with Next.js 15 and the necessity to invoke use(searchParams) in client-side components.

[wellitongervickas]

Not even the AI could help here hahaha

[wellitongervickas]

I'd suggest take a look here: #58351 (reply in thread)