-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
for-of does not work with some DOM collections when target is ES6 #2695
Comments
@zhengbli would this be covered in your change? |
(This would also require making two versions of dom.d.ts - for ES5 and ES6.) |
yup. that is correct. |
This should also be supported in ES3/ES5 since the emitted loop is just looping over the indexes. |
iterators relay on symbols and these are defined in ES6. I think what we need is to allow iterating |
Please do not forget to include in this list |
@saschanaz has added support for:
The other interfaces do not seem to be iterable in the spec. @Arnavion any ideas? |
They're not NodeList is also supposed to be ArrayClass instead of The array iterator On the other hand, Array.from() works for them since they are array-likes, and even in TS they implicitly extend ArrayLike<T> so Array.from()'s signature is not a problem. So that's an argument against allowing for-of for these types in TS. So basically, from the user's point of view, either they use a polyfill for Array.from, and use Array.from to convert all their DOM collections before using for-of. This requires no change from TS, and such a polyfill already exists. (Then there was no point to adding [Symbol.iterator] to NodeList either, but anyway...) Or, TS allows for-of with all DOM collections, and the user uses a polyfill that adds [Symbol.iterator] properties to all those collections. This does require change from TS, and such a polyfill doesn't already exist. I don't have an opinion either way. |
Neither NodeList and DOMTokenList are supposed to be Array subclasses. They are only supposed to be iterable, as in:
|
@IMPinball Yes they are supposed to be, per the spec. I gave links for the other CSSOM objects in the previous post, and the link for NodeList is here where you can also see it's described as ArrayClass. I already explained that no browser has actually implemented them as ArrayClass. Edit: I see you're specifically talking about the whatwg's spec. Sure, that's the one browsers are more likely to implement anyway. However also note that whether they are ArrayClass or not is not relevant to this issue. |
@Arnavion I see what you're talking about in the edit...This bug is actually about the following problem: interface Foo {
*[Symbol.iterator](): Iterator<any>;
}
declare class Bar {
*[Symbol.iterator](): Iterator<any>;
}
declare let baz: {
*[Symbol.iterator](): Iterator<any>;
};
declare let foo: Foo;
let bar = new Bar();
for (let _ of foo) {} // Fail?
for (let _ of bar) {} // Fail?
for (let _ of baz) {} // Fail? Does that repro in any of the three cases? I don't have a dev version handy to test it. |
Without the |
Okay...that is probably trivial |
Unless it's something else...the declarations already exist. |
That file was merged on June 5. |
Please read this thread... |
It type-checks for me with the master branch with |
PRs welcomed. The change should be in https://github.com/Microsoft/TypeScript/blob/master/src/lib/dom.iterable.d.ts |
@mhegazy Please consider microsoft/TypeScript-DOM-lib-generator#235 too ;) |
This has had no activity for a year - is it still considered a problem? The issue still appears to be extant: const collection: HTMLCollection = getCollection();
const arrayCopy = [...collection]; // (TS) Type must have a '[Symbol.iterator]()' method that returns an iterator. |
@KeithHenry I've been actively fixing wrong types on https://github.com/Microsoft/TSJS-lib-generator, I think this also will be fixed within months, or you can send your own PR there. |
@saschanaz cheers, but that already has |
@KeithHenry That file should replace lib.dom.iterable.d.ts but the upstream does not yet support methods including |
What do you mean by upstream does not support, do you mean iterators, in general, are broken? or is this purely a type definition issue? |
Ah, by upstream I mean this one. |
This can be closed now as lib.dom.iterable.d.ts have iterators for MediaList, StyleSheetList, CSSRuleList, and many more. |
This problem still exists for me when trying to iterate over Some code: const triggers = element.querySelectorAll('.trigger');
for (const trigger of triggers) {
console.log(trigger);
} The error is on The error:
Technically correct. A NodeList is indeed neither an array nor a string. But The above code compiles and works fine. So why complain about something that plainly isn't the case? |
@thany Ensure the target is ES6 or higher. Currently TS does not support for-of on general iterable objects when the target is ES5/ES3. |
Or enable |
First of all, why does TS need to support it at all? It just needs to output the transpiled JS and let JS handle whether the object can be looped over or not. Apart from that, NodeList is always iterable, in every browser. Some require a indexed for-loop, newer browser suport for..of. But either way the object can be looped over perfectly fine. If the target is ES5, produce a classic for-loop. I don't see how this is complicated in any way. |
@thany Have you tried --downlevelIteration (introduced in TS2.3, I forgot about it 😅)? I think that should work. |
I've enabled Also since the update, VS Code has switched to TS 3.3.1, in case you didn't know. |
Update: This issue is now only for the following collections:
Originally it was about NodeList as well, but that was fixed (along with DOMTokenList) in #3393
Original:
Seems it just needs an update to lib.es6.d.ts to add the
[Symbol.iterator()]
to all the collections that have an indexer and length property.The ones I found that have it in Nightly are below. The rest were either IE-only or didn't exist.Removed my list since it seems FF has more than the specs allow. See zloirock/core-js#137 (comment) for a more accurate list.The text was updated successfully, but these errors were encountered: