Promise for typeof searchParamsCache.parse

[rwieruch]

Hi there! I have the following setup with v2 with Next App Router:

import { createSearchParamsCache, parseAsString } from "nuqs/server";

export const searchParamsCache = createSearchParamsCache({
  search: parseAsString.withDefault(""),
  sort: parseAsString.withDefault(""),
});

export type ParsedSearchParams = ReturnType<typeof searchParamsCache.parse>;

Then I use the parser on page level:

<MyComponent searchParams={searchParamsCache.parse(await searchParams)} />

But then I get the following type for ParsedSearchParams which I want to use to type searchParams in MyComponent:

(property) searchParams: Promise<{
    readonly search: string;
    readonly sort: string;
}>

Shouldn't it be the following, because I awaited the Promise of searchParams in the page component already?

(property) searchParams: {
    readonly search: string;
    readonly sort: string;
}

Using the following type definition would work, but I am not sure why the change:

export type ParsedSearchParams = Awaited<
  ReturnType<typeof searchParamsCache.parse>
>;

[franky47]

Ah, the parse function has two overloads, one sync and one async. I guess the ReturnType takes the second one, not sure how to force it to lock onto a particular overload.. (edit: looks like we can't, source).

Alternatively, you could use the built-in parser inference helper, but it requires splitting your definition in two (parsers + cache):

import { createSearchParamsCache, parseAsString, type inferParserType } from "nuqs/server";

// Note: you could also export this if using useQueryStates
const searchParams = {
  search: parseAsString.withDefault(""),
  sort: parseAsString.withDefault(""),
}

export const searchParamsCache = createSearchParamsCache(searchParams);

export type ParsedSearchParams = inferParserType<typeof searchParams>

[rwieruch]

Thanks François for the quick turnaround 🚀 Okay, I see both overloads, but TIL that ReturnType only gives one of them (?). Anyway, appreciated the utility! I will keep Awaited otherwise the code structure would change too much for my case.

What's the reasoning behind the Promise overload? Isn't it required to await the searchParams beforehand?

[franky47]

I think the idea was to allow promise-chaining the parser if you needed to enable PPR and statically render the outer shell, while passing the parsed params promise down to be awaited within a Suspense boundary before nested components read the values.

But it breaks the concept of avoiding prop drilling, so I tried an alternative method in an experimental branch (see #724), where the reads would be async too. I ended up discarding the idea altogether due to a tweet by Sebastian Markbåge that using React's cache this way, as a Context replacement, is likely to break in the future. Not sure what kind of API we could leverage to replace it though..

[rwieruch]

Thanks for the explanation François :) Keep it up wtih nuqs 🚀