Return the same interface from both Server Components searchParams and useSearchParams()

[trezy]

Describe the feature you'd like to request

In Next 13, server components' props.searchParams is a plain object. In client components, useSearchParams() returns an instance of ReadOnlyURLSearchParams.

These are 2 completely different interfaces, introducing unnecessary complexity when building APIs that are reusable in both server and client components.

Describe the solution you'd like

Server components' props.searchParams should be an instance of ReadOnlyURLSearchParams.

Describe alternatives you've considered

Alternatively, useSearchParams() could return a plain object. However, URLSearchParams has been supported since Node v10 and is the proper interface for URL query parameters, so I think this would be the wrong approach.

[brielov]

Landed here for the same thing. URLSearchParams would be the standard way to go.

[hyperscientist]

With @types/[email protected] there seems to be another issue with ReadonlyURLSearchParams:
const searchParams = useSearchParams(); new URLSearchParams(searchParams);

error TS2345: Argument of type 'ReadonlyURLSearchParams' is not assignable to parameter of type 'string | URLSearchParams | Record<string, string> | string[][] | undefined'.
  Property 'size' is missing in type 'ReadonlyURLSearchParams' but required in type 'URLSearchParams'.

[danieltott]

Ran in to this as well. The example code at the bottom of the useSearchParams page is now incorrect. I had to use the following workaround:

export default function ExampleClientComponent() {
  const router = useRouter();
  const pathname = usePathname();
-  const searchParams = useSearchParams()!;
+  const searchParams = useSearchParams()! as unknown as URLSearchParams;

  // Get a new searchParams string by merging the current
  // searchParams with a provided key/value pair
  const createQueryString = useCallback(
    (name: string, value: string) => {
      const params = new URLSearchParams(searchParams);
      params.set(name, value);

      return params.toString();
    },
    [searchParams],
  );

  return (
    <>
      <p>Sort By</p>

      {/* using useRouter */}
      <button
        onClick={() => {
          // <pathname>?sort=asc
          router.push(pathname + '?' + createQueryString('sort', 'asc'));
        }}
      >
        ASC
      </button>

      {/* using <Link> */}
      <Link
        href={
          // <pathname>?sort=desc
          pathname + '?' + createQueryString('sort', 'desc')
        }
      >
        DESC
      </Link>
    </>
  );
}

[hyperscientist]

@danieltott: I prefer to use @ts-expect-error to ignore this error because linter will then remind me once next.js is updated and I can remove this workaround