Coerce query params to string - alternate solution

[jochenberger]

See #3863:
On one of my pages, where I have a paging table, I store the page number as a query parameter. I use a number in the Link target, e.g. Page 2.
When the component re-renders after I click on the Link, props.location.query.page is a number. However, if I reload the page so that window.location.search is parsed again, props.location.query.page is a string.
Please review #4107 before this.
See also #4099.

[jochenberger]

Should it even let undefined through here? If we parse ?b, the query won't have an a key.

[mjackson]

I'm afraid this PR is out of date. We're totally out of the query parsing/stringifying game in v4. All we give you is the string version, location.search. Parsing and serializing are in userland now.

[nikitatrifan]

@mjackson could you explain, please, why you're "totally out of the query parsing/stringifying game in v4"?

[mjackson]

@expdevelop A few reasons:

• Letting users do their own query parsing/stringifying gives them more flexibility. They can choose to use node's querystring lib, Browserify's querystring shim in the browser, qs, query-string or anything else they prefer. There are quite a few options, and they each have different strengths.
• It's a lot easier and faster to compare location.search === otherLocation.search than deepEqual(location.search, otherLocation.search). This benefit plays out in lots of places both inside the router and in userland code.
• Not shipping a query lib with the router lets us be significantly more lightweight.

Also, it's an easy switch for users!

<Link to={{ query }}>
// becomes
<Link to={{ search: stringify(query) }}>

If you find yourself doing this a lot, you'll probably wanna just wrap <Link>:

import stringify from 'my-fav-qs-lib'

const LinkWithQuery = ({ to, ...props }) => (
  <Link {...props} to={{ ...to, search: stringify(to.query) }}/>
)

<LinkWithQuery to={{ query }}>