-
Notifications
You must be signed in to change notification settings - Fork 285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider support for ES2015 iterator protocol for NodeIterator #147
Comments
@bzbarsky doing this would require quite some IDL support I think. Do we really care enough about these objects to continue to maintain them and add new features? |
I ran into this too. As there is no way to select Text Nodes with selectors, using Node Iterator is still something we need to fallback to. It mean having to create an node iterator, for which I then needed an ES iterator. |
I would love to see TreeWalker be iterable as well. |
Agree also about TreeWalker... Having to use a generator is not ideal. For example: |
@annevk would adding |
You would also have to define the behavior. But if we wanted people to use these APIs we should also add constructors and modernize them a bit. It's just not clear to me they have the use that warrants such an investment. If you compare |
To me it's one of those areas where it's not used often but when it's needed there are no alternatives (same for TreeWalker) - that I know of. I'm happy to put the work in to define what |
I mean the alternative is to just write the iteration code yourself, right? That'll likely be faster due to the lack of boundary-crossing, and it'll be easier to read and understand without someone having to go look up this esoteric API. I think the first step here would be demonstrating why it's so bad to write loops in JavaScript. |
As in manually looping over |
Yeah, creating your own tree walker. You could use |
Do you think it is worth documenting this in MDN - discouraging use of |
I agree, these APIs definitely definitely aren't perfect. There is confusing overlap between I still think they can be useful -- it's nice to have a built-in API to give you the confidence you're not making a significant performance blunder. I wouldn't mind keeping them around with some improvements.
I'm not convinced the comparison is valid here. If you need to iterate over a flat array of elements,
This is a fair point -- a simple lazy tree-walker can be built with a recursive generator: function* walkNodeTree(root) {
yield root;
for (const node of root.childNodes) yield* walkNodeTree(node);
} This isn't hard, but it's also not completely trivial. Add on support for skipping individual nodes / rejecting node subtrees and the logic starts to get a little more complex. And I doubt there are many browsers that will tail-call optimize a generator, so you'll probably want to add a trampoline.... there's plenty of subtle considerations here.
It seems to me that the primary advantage of the original feature request (adding iterator support) would actually be that it makes these APIs easier to use with loops ( |
ES2015 introduces support for iteration protocols. Iterators are objects with
.next
method which return object{value: value, done: true/false}
.Iterables are objects with
Symbol.iterator
method that returns iterator.Making NodeIterator an iterator would be non-breaking change that will allow simple iteration of object using
for-of
loop or converting results to static array by spread operator.Simplest implementation would be:
I think real specification should include cloning "initial state" of NodeIterator to allow multiple iterations over the same NodeIterator.
Similar logic can be applied to
XPathResult
objects that exposeiterateNext
method.Related Firefox bug.
The text was updated successfully, but these errors were encountered: