should use URLSearchParams first then fallback to buildQueryString / parseQueryString

[futurist]

Expected Behavior

URLSearchParams is supported since Chrome49, although IE don't support it, but it is already standardized.

Also in Node 10, The WHATWG URL API is now a global, which means server side will heavily depends on new URL(), this means that client side want to align with server side under a same way of encoding/decoding of search params.

Current Behavior

Current behavior of queryString in mithril doesn't aligned to the standard in some corner cases, which lead to developer include some polyfill finally.

Possible Solution

If possible, the queryString part of mithril should align to URLSearchParams behavior, use it first then fallback to a polyfill, just like Promise does.

At a glance, I think the polyfill for mithril could just contains a constructor(from string or object), get and keys/entries method.

[pygy]

Thanks for the heads up! That's a good suggestion.

Alternatively, we could replace buildQueryString / parseQueryString with a URLSearchParams polyfill (like we replaced the A+ non-compliant Promise implementation with one that matches ES6 (and thereby A+).

[futurist]

Although I'm go along with polyfill within mithril, but happy to see mithril will eventually remove all these polyfill, that should be the job of user, like many does for ES5 Shim in the old days, lib developer suppose the user already have and job will be more easier 😄

[dead-claudia]

Is this going to make it to v2, or does it need to be punted until the next major version? Since it's only just now in Node 10, I'm thinking punt it.