useQueries constructs URLs with hash fragments and query strings out of order

[timdorr]

Specifically, in appendQuery, it appends the query string after pathname, which could include a hash fragment. This causes issues Link in react-router to direct to the wrong URL.

[timdorr]

Mentioned in remix-run/react-router#2224.

[mjackson]

I wonder if useQueries should put a 3rd arg into createPath (and pushState, replaceState, etc.). So

history.createPath({ the: 'state' }, '/the/path', { the: 'query' }, '#the-hash')

That, to me, feels cleaner than

history.createPath({ the: 'state' }, '/the/path#the-hash', { the: 'query' })

[taion]

Worth considering what this means w/r/t #16 - would we be okay with hash being a no-op arg in that context?

[mjackson]

We just use the hash to build a URL. I don't see why they couldn't find some use for it on native if they wanted to.

[timdorr]

@mjackson The only issue I have with adding another field is that it gets away from the function name. useQueries sounds like it's just for queries in your URL. Maybe if it were useLocations or if pushState accepted Location objects?

Maybe the short term fix is to not mangle pathnames with hash fragments and the longer term fix is a change to the API?

[mjackson]

In my mind useQueries means "add query parsing/stringifying to my history object so I don't have to do it manually". I think the extra arg works in that case.

[timdorr]

I wonder if this would fit with remix-run/react-router#2186. That is, if useQueries could enhance pushState to accept both string and object locations.

And I'm reminded that I miss keyword args from Ruby right now 😉

[mjackson]

I actually had a similar thought, @timdorr. Everywhere we accept a path we should also accept an object. useQueries would add the ability to put a query property on that object.

[mjackson]

I added the ability to use a { pathname, search, hash } object anywhere you can use a path.