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

[James Greene]

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
> >
>