Should createSearchParamsCache(..).parse fail if called twice? Using it in generateMetadata.

[rikbrown]

Hi!

Love the library, has reduced a 1000s of lines of code to much less for some complex search param stuff I'm using.

But quick q: I'm using the SSR cached parser, and happen to be using it both in the main page function and the generateMetadata function (I want to use some of the search parameters for metadata, and it's convenient to have them parsed in my case).

Next.js runs both of these in the same "page lifecycle" (or whatever it's called), so the cache persists between them. However, I don't think there's a guarantee which one will run first (if there is, this is irrelevant, but couldn't find it documented). This means I have to call parse in both to be sure of having the data. However, the second parse call fails with Search params cache already populated. Have you called parse twice?.

I think it'd be nice to have an option to silently succeed and return the existing value in this case? I can understand why you wouldn't want this to be a default for API correctness, but making the call idempotent would be really useful here. I think I'm going to need to wrap it inside a second cache(..) so it only gets called once as a workaround.

Cheers

[rikbrown]

(I wrapped it like this for now, where _searchParamsCache is the return of createSearchParamsCache)

export const searchParamsCache = cache((searchParams?: Parameters<typeof _searchParamsCache.parse>[0]) => {
  if (searchParams) return _searchParamsCache.parse(searchParams)
  return _searchParamsCache.all()
})

[franky47]

Yes, that would make a lot of sense. Come to think of it, having the idempotent behaviour by default would also make sense. The error was put in place to allow detecting places down the tree that would re-assign (poison) search params values by calling parse again on the same cache object with different inputs. In that case, we can still throw the error, but if the same input is used again, we can safely return the cached parsed param values.

[rikbrown]

Awesome, yeah makes sense only to throw if it's different input. I'm happy to take a stab at it later today if you'd accept a PR!

[rikbrown]

#557

Took a stab at it here, let me know if this looks reasonable or if you'd prefer a different approach.