Current implementation of parsing query params from href can lead to no results being returned

[WojciechMatuszewski]

Describe the bug
Current implementation parses and creates queryParams from this.href (see page.ts or cursor-based-page.ts). That is completely fine, however, we should be very careful how some characters get encoded by axios library.

To Reproduce
Steps to reproduce the behavior:

1. Perform any kind of search which returns Page and there are more results to fetch (query has to contain at least one space)
2. invoke getNextPage() on that Page
3. See results prop on returned Page is an empty array.

const page = await spotify.searchTracks('lil pe');
const page2 = await page.getNextPage();
console.log(page.hasNext(), page2.items.length); // true, 0

Expected behavior
returned Page contains newly fetched items.

Additional context
The cause of this bug was not obvious for me at first.
Call to getNextPage() uses queryParams which parses them from this.href.
That causes some params (query in this case) to have some symbols double parsed by axios (once from initial request, once from the subsequent request which passes already parsed URL params to axios)

Example:

// q=lil+pe => everything is fine (notice lil+pe) 👍
const page = await spotify.searchTracks('lil pe');

/*
query=lil%2Bpe
We passed {query: 'lil+pe'} instead of {query: 'lil pe'} to axios params.
That caused axios to parse + as %2B which causes Spotify to return no results
*/
const page2 = await page.getNextPage();

[JoseRenan]

Nice observation! So, if I understand the problem, the solution could be decoding this value before getting the query params, right?

[WojciechMatuszewski]

Not sure, the easiest solution would be to just replace + with spaces and then splitting this.href. But, imo, that is more like a bandaid than a solution

[JoseRenan]

Hmm, we could keep the raw query params in the page object, I think it's the most elegant solution 🤔

[JRobsonJr]

I think using the decodeURI function would be the best solution in this case. It should work just fine for this purpose, right?

Edit: Just saw that Spotify itself encodes spaces as +. I think that we need to do as @JoseRenan suggested, because replacing + with spaces could modify the original intent of the person making the search (if they actually put + in their query).