[whatwg] iterators intead of live NodeLists WAS: Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

[Ojan Vafai]

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.

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.


On Sat, Jul 27, 2013 at 12:42 PM, James Greene <james.m.greene at gmail.com>wrote:

> Isn't that what the NodeIterator and TreeWalker APIs are for?
>
> Sincerely,
>    James Greene
> On Jul 27, 2013 1:25 PM, "Ojan Vafai" <ojan at chromium.org> wrote:
>
>> Realized this should probably be a new thread...
>>
>>
>> On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <ojan at chromium.org> wrote:
>>
>> > On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking <jonas at sicking.cc>
>> wrote:
>> >
>> >> On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky <bzbarsky at mit.edu>
>> wrote:
>> >> > On 7/24/13 10:42 PM, Jussi Kalliokoski wrote:
>> >> >>
>> >> >> Argh, I had forgotten about live NodeLists. OK, this is a reason
>> that
>> >> >> resonates with me and justifies calling these methods obsolete. Too
>> bad
>> >> >> these methods are so badly flawed
>> >> >
>> >> >
>> >> > Fwiw, I think the performance impact of live NodeLists is ...
>> unclear.
>> >> Their
>> >> > existence does mean that you have to deal with DOM mutations changing
>> >> the
>> >> > lists, but them being live also means you can make the list getters
>> much
>> >> > faster in cases when the caller doesn't actually want the entire
>> list.
>> >>
>> >> And, as importantly, it also means that for multiple consecutive calls
>> >> to get the list, say inside of a loop, can return the same result
>> >> object. I.e. you don't have to re-walk the DOM for every iteration
>> >> through the loop.
>> >>
>> >
>> > I think these are good points of what is lost by using static
>> NodeLists. I
>> > still feel pretty strongly though that these benefits don't outweigh the
>> > costs. If we want to give people most of the benefits of live NodeLists
>> > without the costs we could expose an iterator API:
>> >
>> > var iterator = document.querySelectorAll('div').iterator(); <--- does
>> some
>> > magic to not precompute the whole list
>> > 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 gets the performance benefits of live NodeLists, I think meets the
>> > main use-cases of not wanting to walk the whole DOM, but doesn't require
>> > the browser to do a lot of metadata tracking as you go.
>> >
>> > Ojan
>> >
>>
>