-
Notifications
You must be signed in to change notification settings - Fork 28.7k
Explain how to use searchParams prop #80579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I think this is a glaring omission from the docs that makes it very difficult to understand how to use these API right. See [this discussion on Reddit](https://www.reddit.com/r/reactjs/comments/1lar2ss/comment/my2e3kl/). I took a minimal approach but really this should be properly explained somewhere because nobody knows this prop exists.
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
Let's merge this, and plan an additional section to:
A (Titles are not final) |
@@ -72,6 +72,7 @@ const searchParams = useSearchParams() | |||
> **Good to know**: | |||
> | |||
> - `useSearchParams` is a [Client Component](/docs/app/getting-started/server-and-client-components) hook and is **not supported** in [Server Components](/docs/app/getting-started/server-and-client-components) to prevent stale values during [partial rendering](/docs/app/getting-started/linking-and-navigating#client-side-transitions). | |||
> - If you want to fetch data in a Server Component based on search params, it's often a better option to read the [`searchParams` prop](/docs/app/api-reference/file-conventions/page#searchparams-optional) of the corresponding Page. You can then pass it down by props to any component (Server or Client) within that Page. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've found passing searchParams
down to Client Components can be a bit of an anti-pattern since there are situations where you might update them without revalidating the Server Component.
This can happen when doing "shallow" updates, that is, call window.history.pushState
(or replace) directly, which updates the page without going to the server, as described in Shallow routing on the client.
This is a pretty popular approach because nuqs does it by default, so maybe mentioning you can do that here without additional context (which might be out of place here?) might lead some people down a painful path?
I don't have strong feelings though and think this is a great update to the docs, just wanted to mention it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taking this into account for a Getting Started/Guide section.
I think this is a glaring omission from the docs that makes it very difficult to understand how to use these API right.
See this discussion on Reddit.
I took a minimal approach but really this should be properly explained somewhere because nobody knows this prop exists.