Error parsing through Tanstack Router standard schema

[missile-developer]

I think I found that it error when I try to parse using parseAsArray or parseAsIsoDateTime. Any limitations on standard schema?

[franky47]

Those parsers are unfortunately not supported for type-safe linking in TanStack Router due to how deserialisation is done there (at the root router level, and using a single interface for all search params).

Only parsers that parse from strings, numbers, booleans or JSON are supported for type-safe linking. TanStack Router recommends custom data types be encoded in JSON format.

See the caveats in the docs: https://nuqs.47ng.com/docs/adapters#type-safe-routing-via-validatesearch

[missile-developer]

Then any recommend way that I can totally validate search params? Here is my current approach; Will it be okay or not make any senses?

import { createSearchParamsCache } from 'nuqs/server'

const searchParams = {
 lat: parseAsString
}

const validateSearchParams = createSearchParamsCache(searchParams)

const rawSearchParams = Route.useSearch({ strict: false })
const validate = validateSearchParams.parse()

[franky47]

createSearchParamsCache is only available for Next.js app router, for a one-off parsing of search params you should use loaders, which do the same thing but without the use of React's cache function.

To be fair, unless you have external components that use nuqs and you need to use them in your TSR app, you're probably better off using TSR's APIs directly (useSearch, useLocation etc) in your application code, as the nuqs adapter is experimental and only provided for a compatibility layer.

[missile-developer]

I see, thanks for the suggestion. For me, I ended up using shadcn-table. so, actually I already tried to unplug the nuqs before. Using only tanstack table might be ideal for me. Unfortunately! it's a bit complex to extract it since the whole concept already bind with nuqs.

[balzdur]

I'm not sure to have all constraints about the deserialisation issue in TanStack Router but to be sure you know it, the framework allow to customise search param serialization (maybe it is the missing stuff you need to raise your caveat)

[franky47]

Yes, it would be great if this would allow to access which key is being (de)serialised, so we could connect that to nuqs somehow (aside from the fact that hoisting the parsers to the router level would be a pain).

But since the key isn't known, and providing it would break the default JSON.stringify behaviour, it doesn't really help unfortunately.