Sort URLSearchParams prior to stringification

[jeffposnick]

Inspired by this tweet, I'd argue that the specified behavior for the URLSearchParams stringifier should be changed to either automatically sort by default (unlikely, due to @annevk's objections), or alternatively to support some sort of boolean opt-in to enable sorting.

I'd imagine that sorting based on parameter names, falling back to parameter values in the case of repeated parameters, would make the most sense.

[kornelski]

I suggest allowing constructor to take an Object and set names/values from object's sorted properties.

I think this would be a nice and convenient opt-in.

[domenic]

Since URLSearchParams with a different order is actually different semantically, it would make more sense to have something like usp.sorted() that returns a new URLSearchParams object with the order re-shuffled.

[annevk]

@domenic should that be similar to Array.prototype.sort()? If we add it here I guess we'd want it for FormData and Headers too? And Map objects? Not sure if this really needs to be standard library yet since it's quite trivial to write I think (have not attempted).

[domenic]

Hmm I'm not sure. If you did want to allow a custom comparator, I'd imagine something like this?

const newUsp = usp.sorted(([k1, v1], [k2, v2]) => v1.localeCompare(v2)); // sort by values

You could start with just a no-arg usp.sorted() that returns them sorted by key, then by value.

[domenic]

If we add it here I guess we'd want it for FormData and Headers too?

Yeah probably.

And Map objects?

Less clear to me, as there's no good default unless you just assume all keys can be converted to strings.

Not sure if this really needs to be standard library yet since it's quite trivial to write I think (have not attempted).

Yeah, it would be good to see some library code with at least moderate use before we try to bake this in...

[annevk]

So looking at this somewhat fresh and rereading the tweet thread it seems this is actually specific to URLSearchParams since it affects cache interactions. Neither Headers nor FormData encounter such a scenario. It also seems that a simple lexical sort should be sufficient here and that you actually do want to affect the current instance.

@igrigorik does that sound about right?

If that is correct, just adding a sort() member which uses lexical sort to sort the existing items in the list (using name as the sort key) seems like the way to go.

[annevk]

@igrigorik @jeffposnick ping.

[jeffposnick]

👍 to the suggestion at #26 (comment)

[jasnell]

If this were to happen, having the new sort() operate the same basic way as Array.prototype.sort() would be ideal, I think. Sort in place with the default sorting on the Unicode codepoint of the keys without value sorting, but allowing a compareFunction to be passed in. The function should sort in place and not be stable.

The reason for the default sort not affecting the value order is that ordering of the values can be significant. We should not assume that it's ok to move the order of the values around.

[igrigorik]

@annevk yep, another 👍 for #26 (comment).

[annevk]

@jasnell I was hoping to go with the minimum viable solution here. If you need a callback, you might as well write a quick forEach() or some such. Only sorting keys seems reasonable though.

[jasnell]

I can live with that