Support customization of query string serializer in redux-resource-xhr

[whichsteveyp]

One of my APIs that I proxy through my webserver actually requires a query string that looks something like this:

http://service/path/to/handler?id=1&id=2&id=3&etc...

If you look at the qs lib they allow for configuration of arrays in a few ways, like so:

qs.stringify({ a: ['b', 'c'] }, { arrayFormat: 'indices' })
// 'a[0]=b&a[1]=c'
qs.stringify({ a: ['b', 'c'] }, { arrayFormat: 'brackets' })
// 'a[]=b&a[]=c'
qs.stringify({ a: ['b', 'c'] }, { arrayFormat: 'repeat' })
// 'a=b&a=c'

It seems the current options I have are:

1. qs-ify my URI prior to passing it in to the action-reactor
2. transform it on the webserver layer before handing it off to the server

This is due to limitations of the existing qs options we can patch onto the xhr under-the-hood, like so:

const xhrOptions = {
    json: true,
    url: `/api/my/url`,
    qs: {id: ids},
  };

This produces an XHR to a URI that looks something like this by default:

/api/my/url&id=1,2,3

I spoke with @jmeas offline about this, and there's a few ways we can approach this, but wanted to post that here so we could capture the discussion and then once we figure out the desired changes (if any) we can reference it here.

Thoughts?

[whichsteveyp]

I know earlier we talked about both the impacts in 'over heard' for a flexible API from a maintenance and API surface area for users, but one thing we could consider adding is allowing qs here to be either:

1. Something we can pass to our internal qs method and use to build a URI
2. A function that can be invoked (possibly with other URI strings?) to handle the qs.stringify however users prefer.

Just some random thoughts on it - and I think you mentioned that approach awhile back too.

[jamesplease]

The API should mirror what's outlined here:

naugtur/xhr#160 (comment)

so that this lib is an easy transition to [email protected]

[jamesplease]

I'd be alright with merging just about any API that implements this. If it follows what xhr plans to add in v3, then that's awesome, but not a requirement. PRs welcome!