GET request URL string with multiple values for one parameter

[a1exsh]

I've seen the discussion in #47, but my case is subtly different.

I need to call an API with a URL which contains multiple values for the same parameter (a list parameter), but I'm not building the URL: I'm receiving it as part of response from the API. So I can't just use the :query-params option unless I parse the URL myself before making the request. And I can't use parse-url because it ignores the multiple values:

=> (:query-params (cljs-http.client/parse-url "http://example.com/?a=1&b=2&a=3"))
{:a "3", :b "2"}

Cannot we really avoid parsing and building the URL in the cljs-http.client?

[r0man]

Yes, let's try to not parse the :url key in the request map and pass it unmodified to XHR. Patch welcome!

…

On Tue, Mar 27, 2018, 15:23 a1exsh ***@***.***> wrote: I've seen the discussion here, but my case is subtly different: #47 <#47> I need to call an API with a URL which contains multiple values for the same parameter (a list parameter), but I'm not building the URL: I'm receiving it as part of response from the API. So I can't just use the :query-params option unless I parse the URL myself before making the request. And I can't use parse-url because it ignores the multiple values: => (:query-params (cljs-http.client/parse-url "http://example.com/?a=1&b=2&a=3")) {:a "3", :b "2"} Cannot we really avoid parsing and building the URL in the cljs-http.client? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABUPsi08VCO3RR7DRiN2ji9lU1RvuLEks5tij1MgaJpZM4S86h5> .

[a1exsh]

Yeah, I now see it is bit more complex.

Not parsing and re-building the URL will solve the case when you only have the :url and no additional params. But since the client already supports mixing :url and :query-params in a request, we would still have to parse it occasionally.

I wonder if we should rather make the parsing and building more flexible in order to be able to accommodate list parameters? E.g. adding an option to parse-query-params to collect multiple params in a list value, but keep the default behavior as it is now. At the same time generate-query-string should learn to handle list values.

[a1exsh]

Wait, generate-query-string is already aware of list handling, so this part is a no-brainer. ;)

[a1exsh]

After some consideration I believe that we should have the behavior of parsing into list by default, w/o an additional parameter to control this. This ensures that the URL is preserved in the process of parsing and rebuilding. If someone wants a finer control, the URL can still be parsed and adjusted to taste.

Opened a PR: #116

[a1exsh]

OK, let's close this now since #116 is merged. :)