Should serialize() return the string ? for all-nullish params? (+1 issue)

[MartinCura]

tl;dr: should serialize({ ... }) with all params as null/undefined return ? instead of an empty string?

Hey there! Awesome library you've got there, finally found a reason to use it and i never think i'd be so happy writing a paginator component (though it is beautiful).

Using nuqs 2.2.0 (coincidentally released 1 h before i installed it).

I'm on Next.js and for this component experimenting with doing everything SSR, with just hrefs to move between states. I may later realize this is not the best approach and i'll go back to some client behaviour but i'm liking it so far.

Here's some of my code, if of any use

```ts const productDetailParamsParsers = { section: parseAsStringLiteral(["section-1", "section-2"]), page: pageIndexParser.withOptions({ clearOnDefault: false }).withDefault(0), } const productDetailUrlKeys = { section: "seccion", page: "pagina" } as const export const productDetailParamsCache = createSearchParamsCache(productDetailParamsParsers, { urlKeys: productDetailUrlKeys, }) export const serializeProductDetailParams = createSerializer(productDetailParamsParsers, { urlKeys: productDetailUrlKeys, }) ``` (Sorry for bad rendering in GitHub)

That clearOnDefault: false is better imo here, i prefer the page to be explicitly 1.

Closing a certain modal clears certain search params, so for that i have to do

<Link href={serializeProductDetailParams({ ...rest, section: null, page: undefined }) || "?"}>

With that intro out of the way...

1. The main thing here i'm bringing up is that the serialize() call returns an empty string if everything is nullish, and though i can see this makes some sense it also means it can't be used as a link. Thus the || '?', because href="?" works in clearing the search params, but href="" does nothing. My "proposal" / question comes from the notion that serialize() is used for creating links, so if there are other major use cases my point may not be valid.

2. Setting page: null is not allowed there, luckily i can do page: undefined. Would it not make sense to also allow null in the serialize arg for the param with a default? It's clear to me that i'm trying to clear the param from the URL.

Thanks again for the awesome library!

[franky47]

Regarding point 1, the idea was for the serializer to have the same behaviour as the hooks, which when clearing the URL, don't leave a dangling ?. For links, a better approach would be to pass the current pathname, but since you're trying to do this only server-side, and Next.js doesn't give us a getPathname helper there, you'd have to pass each pathname to the base of the serializer manually. I'd say the || '?' is cleaner code, with a trade-off of a less neat URL.

Regarding point 2, what you'd want is to render the default value of the parser in the resulting URL? That would be a very good addition, since clearOnDefault: false is a strong signal that we want the default value in there.

[MartinCura]

1. Crystal clear. Maybe i'll wrap the serialize creator in my app to add this case but i can see why you'd prefer that behaviour as default, and adding an option for something like this would probably make the API messier.

2. I'll try to make myself clearer just in case. Let's say i have pageParser = parseAsInteger.withOptions({ clearOnDefault: false }).withDefault(0)
   a. page missing in URL =(parse or useQueryState)=> gets 0 as default in code 👍🏼
   b. page=2 in URL ==> gets 2 in code 👍🏼
   c. setPage(0) in code ==> puts page=0 in URL 👍🏼
   c. setPage(null) in code ==> clears from URL but still gets default 0 👍🏼
   d. try to pass page: null to serializer => type error, even though i think the intention is clear

      href={serializeProductDetailParams({ ...rest, section: null, page: undefined }) || "?"}
// (property) section?: "opiniones" | null | undefined ^             ^ (property) page?: number | undefined

In other words: i think it would be fine to accept null for params that code-side are non-nullable (they have a default) but URL-side are "nullable" (because they can be missing). It's a minor thing because i can still pass undefined.

A different interpretation would be to allow passing page: null but for that to somehow put the default in the URL... though i wouldn't prefer that, personally.

Thanks!

[franky47]

Ah I see, you can't pass null to a key that has a default value? That sounds like a bug, it should be accepted and clear the value from the output, just like the rest.

Would you like to try your hand at a PR?

[MartinCura]

Here you go: #769

Code is quite beautiful btw