Add ability to use urlKeys with serializers, improve DX around parser "groups"

[neefrehman]

In our codebase we work with serializers a lot to create hrefs. Recently, we've also been taking advantage of the urlKeys option in useQueryStates, and have noticed that the equivalent is missing with serializers. It would be nice to achieve the same functionality no matter how you're planning to use nuqs, so that the symbols we are working with in code and the search param key can be decoupled, to improve DX.

A further thought that came to mind was an API that would allow us to create a group of parsers that has group-level configuration:

const parsers = createParsers(
  {
    page: parseAsInteger,
    size: parseAsInteger,
    sort: parseAsCustomSortObject,
    query: parseAsString
  },
  { urlKeys: { query: "q" } }
)

It would be nice if this parsers object could be use isomorphically when creating a serializer, or in useQueryStates, and bring along its config with it. This is kind of like how individual parsers work today, where they can be configured ahead of time and used (or extended) in multiple places, though would allow configuration at the group-level. The suggested API is also partly inspired by react-query's queryOptions API, that has some similar characteristics, and allows for much greater flexibility and shareability across the library's surface area.

[franky47]

I like this idea!

We could potentially make the urlKey a function to process the internal keys, so you could implement your kebab-case proposal in #688 this way:

const parsers = createParsers(
  {
    commentsAfter: parseAsString,
    commentCount: parseAsInteger,
  },
  { urlKeys: makeKebabCase }
);

// Not sure what would be the most practical type for input & output here:
function makeKebabCase(input: ??): ??

[neefrehman]

Yes this sounds good!

I think making the callback one that receives and outputs a single string, which is then iterated over internally, might be quite nice. Then the caller could just import any kebabify function from a library, that doesn't have to assume anything about the shape of data received.

[franky47]

urlKeys support for the serializer is being worked on in #720, and should land in 2.1.0.