size (or length) for URLSearchParams

[stevenvachon]

URLSearchParams is basically a Map and should have a size property. The unfortunate alternative is:

Array.from(url.searchParams).length

[annevk]

Well, it's a "multi-map". You can have duplicate keys. But I guess this would just return the length of the underlying list?

@domenic @tabatkins thoughts on naming?

If we add this, we should also update FormData and possibly Headers.

[stevenvachon]

const url = new URL("protocol://domain?query=value1&query=value2&query2=value");
console.log(url.searchParams.size);  // 3

[domenic]

Oh, I would have expected 2, not 3 :(. That indicates to me this may be too confusing of a concept to add, and just using Array.from().length, or asking TC39 to add an %IteratorPrototype%.length so that you can do url.searchParams.keys().length vs. url.searchParams.values().length, would be better.

[tabatkins]

Yeah, MultiMaps are intended to be usable as Maps, too, and the difference in expected size between the two use-cases is a footgun if you make the choice either way. +1 to adding .length to iterators.

[annevk]

Leaving this open for now as documenting these multimap design decisions somewhere is probably worthwhile.

[annevk]

@domenic what is the likelihood of TC39 adding such an extension? An alternative is that we have size and sizeAll, in line with other members...

[domenic]

It's really hard for me to say... we could try proposing it.

[tabatkins]

Given the use of MultiMaps in the CSS Typed OM, we really should make this a formal thing.

[eligrey]

Lack of a built-in size getter results in developers writing code like this:

if ([...searchParams].length !== 0) {
  // ...
}

as opposed to this (more efficient, but harder to read):

if (!searchParams.entries().next().done) {
  // ...
}

A size getter could be optimized by the JS implementation so that searchParams.size !== 0 checks could be more efficient than [...searchParams].length !== 0.

[WORMSS]

Yes, as @eligrey has pointed out, I was in the need of a 'do you have any values, yes? no?' I didn't actually care that much about the full count..
In the end I actually just did

const qs = urlParams.toString();
if (qs.length) {
  return `?${qs}`;
}
return '';

Not quite as nice looking, but it got the job done.

[annevk]

Hmm, isEmpty() doesn't seem entirely out of the question. Though there's no precedent in JS land.

[jasnell]

Would the iterator helpers proposals be of use here: https://github.com/tc39/proposal-iterator-helpers

[tabatkins]

Iterator helpers doesn't have a way to count an arbitrary iterable, so no.

[tabatkins]

That said, since the behavior of [...url.searchParams] is to produce a list of entries, I think the clear winner between "count distinct keys" and "count entries" is the latter; aka the earlier example should return 3.

URLSearchParams doesn't provide any simple way to get just the distinct keys; for that you need to manually uniquify them with, say, [...new Set(URLSearchParams.keys())]. So it shouldn't bias towards counting unique keys.

[ricea]

Sorry to show up towing a bikeshed, but how about

unsigned long count(optional USVString key, optional USVString value);

allowing you to do

const p = new URLSearchParams('a=1&b=2&b=3&b=3');
p.count();  // 4
p.count('b');  // 3
p.count('b', '3');  // 2

?

[annevk]

I wouldn't mind that, but with most JS collection APIs having either a size or length getter shouldn't we have that as well?

[zloirock]

I think that there are too many overloads.

The second 2 cases can be solved via .getAll().length and .getAll().filter().length.