x-target.3xx redirect to current page misbehaves when query params have different order

[lachlancotter]

Thanks for this fantastic library. Love the elegance of your approach. However, I ran into some difficulty when needing to swap content or redirect based on the outcome of a form submission (similar case to #79)...

PR #84 introduces a special handling for a _self target on a 3xx redirect:

Any 3xx class status code redirecting to a different page will load the redirected URL in the browser window
Any 3xx class status code redirecting back to the current page will target my_form.

However the URLs are compared as strings:

function sameUrl(urlA, urlB) {
  return (stripTrailingSlash(urlA.pathname) + urlA.search) === (stripTrailingSlash(urlB.pathname) + urlB.search)
}

This makes the behaviour dependant on the order of query params in the current URL and the response location header. If the order differs, this behaviour no longer applies.

If the current page was reached via a form (as in my case), the order of query params depends on the order of form fields. In my case I was able to solve this by sorting my data and using hidden form fields. But that adds complexity and implicit dependencies that could be avoided by comparing the URL queries as Maps.

The meaning of query parameters should generally be order independent.

[imacrayon]

Hey! Thanks for the clear explanation. I totally agree, we need a more robust comparison method.
I’ve got some time set aside today to work down a few issues, this is on my priority list.

[lachlancotter]

Awesome. Thanks! I wonder if would make sense just to leave out the query params entirely for the purposes of matching the current page. The base path is usually the significant part for routing.

[imacrayon]

@lachlancotter you’re right, in that case, I think we can do away with the sameURL and stripTrailingSlash functions and simply compare pathname for equality. That seems to be consistent with how my browser’s URL bar handles sameness.