Selections should be iterable.

[aendra-rininsland]

A thought —

Often I find I use d3-selection for checking the existence of a single element, which is a bit of a rough edge:

1. You have to call .size() even if the selection is the result of d3.select (and thus size will always be either 1 or 0)
2. An empty selection is still truthy

This means you have to explicitly remember to call .size() when existence checking, which sort of is counterintuitive to how selections work via the DOM.

I know the idiom is to act as if selections exist even if they're empty (so data can be bound to them eventually), but if selections were proper iterators there could be a .length property which would make the object falsy if the selection were empty.

Turning selections into proper iterators would also make it possible to use the spread operator on selections and use all the standard array prototype methods (even if it means spreading the selection into an empty array like is frequently done with NodeList objects).

Admittedly I have no idea how feasible or backwards compatible this idea is. 😅

[mbostock]

The length property isn’t part of the iterable protocol, and empty iterables are always truthy because every iterable is necessarily an object (e.g., !![] and !!new Map are true).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols

We could have implemented size as a getter rather than a method, for consistency with ES collections, but those didn’t exist at the time d3-selection was initially designed, and I don’t think it’s worth changing that now.

I do agree that selections should implement the iterable protocol, though, iterating over each non-null node in the selection. Let’s do that for d3-selection 2.0.