Url encoded by URLSearchParams

[tiagogm]

Hey!

I opened this issues because I ran into a small hick. URLSearchParams encodes the query string by default, so this:
date=12/04/2018&other=1,2,3,4 Becomes this: date=12%2F04%2F2018&other=1%2C2%2C3%2C

For my case, I was thinking of being able to configure this as well, since I don't want encoded url to show as much as possible in the address bar.

However, a bigger issue is this line: https://github.com/Treora/redux-query-sync/blob/master/src/redux-query-sync.js#L132

This comparison will fail, even if the query string did not change. Because the value in oldLocationSearchString can be a decoded string and the newLocationSearchString will always be an encoded one.

I'm thinking if just always decoding the string when getting it from URLSearchParams would be a viable option? Or just encoding both and comparing them.

In my case I don't actually want the parser to replace by decoded string for an encoded one unecessarily. Which is what is happening as of now.

Cheers!

[Treora]

The percent-encoding of characters in URLs keeps confusing me. Partly because browsers (at least Firefox and Chromium) convert some characters to percent-encoding as they should, but still render the character in the UI. For example, https://example.com/?q=📇 will be converted to https://example.com/?q=%F0%9F%93%87 (check window.location), but it will show a 📇 emoji in my url bar (%20 to a space being another such). Other characters do not seem to be converted by the browser, though they are converted by e.g. encodeURIComponent, URLSearchParams.toString, or escape. I don't know if there is a single standard that is adhered to, nor what would be the right way to go for us.

In any case, the comparison you mention seems wrong indeed. In the current situation, I suppose it could be fixed by comparing with ?${new URLParameters(oldLocationSearchString)} instead (might that be the same as encodeURIComponent(oldLocationSearchString)?).

Making the output prettier would be nice too, but I am really not sure which values to encode. At least the & and # should be encoded, obviously. But = too, or not? I'd prefer to follow some spec here, rather than just testing what seems to work. Happy to hear if you have a clue.

[tiagogm]

I think regarless how the browser shows the string as long as the encoded string matches the decoded version, it works all the same. I've seen emojis in the some other urls before I was just as confused..

Since URLSearchParams is being used, makes sense to keep it encoded. The .toString() method for of URLSearchParams instance, definitely encodes the string.
https://github.com/WebReflection/url-search-params/blob/master/src/url-search-params.js#L137

However there is some replacing going on in some characters.

So I think for this case the line should be ?${new URLSearchParams(oldLocationSearchString)} to make sure both strins go trough the same transformation before comparing them.

For my use case, I think using the stringToValue and valueToString to encode/decode would work to always read the decoded version.