W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

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

From: Ojan Vafai <ojan@chromium.org>
Date: Sat, 27 Jul 2013 11:25:21 -0700
Message-ID: <CANMdWTtDzbM890rx3j6HVnpHfA-x7Q3sc2o6Y-f81gg2eiKFRA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
Realized this should probably be a new thread...


On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai <ojan@chromium.org> wrote:

> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky <bzbarsky@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
>
Received on Saturday, 27 July 2013 18:26:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC