Allow passing arrays to query string params

[mchudy]

Currently there is no easy way of defining and creating paths with array query params. As there is no recognized standard for encoding arrays in query strings, we should probably have a highly customizable API with built-in support for the most common conventions:

• ?array=item1&array=item2
• ?array[]=item1&array[]=item2
• ?array=item1,item2

API design considerations:

• Should we extend the query string type to string | string[] or provide a new configuration option on a per-param level which specifying whether the param is supposed to be an array or a scalar (so that the type is then narrowed accordingly)?
• We probably need some optional second argument in createRouting where a config would be passed (with properties like encodeQueryParam or queryParamArrayEncodingStrategy). To make it even more elastic, we could also allow overriding those options for single params.
• Should this library also provide some way of decoding raw query strings back to arrays according to the routing config?

[konowrockis]

Should we extend the query string type to string | string[] or provide a new configuration option on a per-param level which specifying whether the param is supposed to be an array or a scalar (so that the type is then narrowed accordingly)?

I think we should go even further and try to support other types like number, number[], bool, bool[] as well. Maybe even objects? I'm not sure how to model that yet. But to me that's a perfect world scenario.

We probably need some optional second argument in createRouting where a config would be passed (with properties like encodeQueryParam or queryParamArrayEncodingStrategy). To make it even more elastic, we could also allow overriding those options for single params.

Under the hood we are using query-string. It already supports variety of options and I think it might be good idea to just directly pass those in createRouting. This gives plenty of flexibility. I'm not sure if I can imagine scenario where you need to configure that per route. That'd also mean that you'd need to know how arguments are serialized per route and how to deserialize on per route basis. That adds another level of flexibility but also another level of complexicity which I don't think is worth it.

Should this library also provide some way of decoding raw query strings back to arrays according to the routing config?

That's a good question. I think if we'd support string | number | bool etc. then we'd need to also include a tool to parse back those arguments (probably with some validation?).

[mchudy]

I'm not sure if I can imagine scenario where you need to configure that per route.

Could be the case with some corporate, legacy API gateways which call different APIs with different standards. Yeah, they should be consistent when it comes to the encoding, but we all know that is not always the case :D But I agree that we shouldn't focus on such a niche case for now, separate routings can always serve as a workaround.