I strongly agree with the use-case, and think some feature for this would be very helpful.
[Mixing up your emails for reply convenience.] On Sat, Jul 27, 2013 at 11:25 AM, Ojan Vafai <[email protected]> wrote: > On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <[email protected]> wrote: >> var iterator = document.querySelectorAll('div').iterator(); <--- does some >> magic to not precompute the whole list Can you describe this magic? It would be nice if this were somehow possible, but I'm not sure how it would be. > There are many places where we expose Sequence<Node> or NodeList that can't > easily be replaced with hand-rolled DOM walking (e.g. getNamedFlows). > > You could imagine NodeIterator taking a Sequence<Node>/NodeList as an > argument to it's constructor instead of adding an iterator method, but I > find the NodeIterator interface to be clunky and awkward. Yeah, having the ability to produce these iterators for any of the currently-static Node lists would be great. But again, not sure how the magic would work. :/ >> while (let current = iterator.next()) { ... } >> >> And next always does the walk from the current node. So, if you add a div >> before the current node, this specific iterator won't hit it, but if you >> add a div after it would. I'm not sure what should happen though if you >> remove the node that's the current node. I think I'm OK with the iterator >> just returning null for the next() call in that case. >> > > Thinking more on this, I think we could make next() still work in the case > where you remove the node by pointing current at the previous node in the > tree. Then you could do things like: > > while (let current = iterator.next()) { current.remove(); } This should be an ES iterator, rather than a custom DOM thing that looks almost exactly like an ES iterator. > I think the methods we'd want here are next, previous, first and last. That > way you can walk the iterator forward or backward. This doesn't overlap > well with NodeIterator's current API. How useful is it to be able to walk an iterator in both directions at the same time? I suppose we can produce an iterator subclass that also has the additional methods we want. ~TJ
