Creation of URLSearchParams from Object/Map

[kornelski]

Currently URLSearchParams cannot be directly created from an Object holding keys and values.

Combination of Object.keys, Array.reduce and append feels like boilderplate given that creation of query strings from objects is a common pattern in popular JS libraries, e.g. jQuery, superagent, node's url.format.

I suggest accepting an Object, Map (or anything that is iterable and has string keys) in the constructor and the set method.

i.e.

URLSearchParams({foo:"bar", baz:"quz"});

or

const tmp = new URLSearchParams();
tmp.set({foo:"bar", baz:"quz"});

could be equivalent to:

const tmp = new URLSearchParams();
tmp.append("baz", "quz");
tmp.append("foo", "bar");

I suggest always sorting the keys, since Object and Map don't guarantee any particular order, but a consistent order is very desirable for improved cacheability of resources.

[domenic]

Yeah probably just match the accepted types in https://fetch.spec.whatwg.org/#headers-class. Although there is no WebIDL spec for this (and thus no bindings in browsers) so it's not that easy.

Map guarantees order (insertion order). Objects guarantee order as well.

[kornelski]

OK, point taken about Object/Map order.

Although order of query string arguments is theoretically meaningful per RFCs—and thus annoyingly problematic for cache hit ratios—I haven't yet seen any server-side framework that cares about order of names*. Most APIs that parse query string expose it as hash/dictionary/associative array.

So I think it wouldn't harm to sort anyway. It's the common case. An extra .sorted() call is easy to forget.

In an edge case where somebody really needs a specific order, they can iterate and .append() themselves (just as the API currently requires).

*) usually order of values with the same name is important, i.e. foo=1&foo=2&foo=3, but that's a different case. I'm assuming stable sort.

[annevk]

I hope that eventually URLSearchParams, Headers, and FormData can all share a bunch of generic infrastructure, so I would not want to sort by default I think...

[annevk]

See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27941 by the way. Passing in an HTMLFormElement similar to FormData...

[annevk]

I created a PR for this. We'll also need tests. I think Gecko would be fairly happy to implement this change.

[annevk]

https://bugzilla.mozilla.org/show_bug.cgi?id=1330678
https://bugs.webkit.org/show_bug.cgi?id=166973
https://bugs.chromium.org/p/chromium/issues/detail?id=680531
Did not file against Edge since it lacks the entire API I believe.

[achristensen07]

I made an initial implementation for WebKit. I find the tests lacking, but it's a start.
So just to be clear, is the order intentionally not specified?

[annevk]

I tried to answer your questions in the WebKit bug. Some additional tests landed at web-platform-tests/wpt#4545. Order is specified everywhere as far as I'm aware, but it's a mixture of IDL, JavaScript, and URL that makes it work for the various pieces involved.