Symbol.asyncIterator on FileSystemDirectoryHandle?

[jimmywarting]

have experimented with the API a bit, could not help but feel like FileSystemDirectoryHandle is missing Symbol.asyncIterator that maps to getEntries

for await (const entry of dirHandle) { ... }

[mkruisselbrink]

Good question, doesn't seem unreasonable to me, although that would also mean that getEntries would be called getValues instead (and possibly there would be a getEntries as well, that would return a iterator of name->child pairs instead). All of that seems not too crazy, although getValues does seem like a bit of a weird name for the method to return the children of a directory...

[DanielHerr]

What does the handle being async iterable have to due with renaming getEntries to getValues?

[mkruisselbrink]

Actually I misremembered things slightly, values() and/or entries() were the methods I was thinking of.

The way WebIDL currently defines async iterables (https://heycam.github.io/webidl/#idl-async-iterable), as well as the proposed additions in whatwg/webidl#808 for value iterables automatically result in a values() method being defined on the async iterable object, as well as possible a entries() and keys() method if it is a pair iterable as opposed to a value iterable.

So in the simplest case of just marking the handle as async iterable<FileSystemHandle>, we would also get a values() method that does what getEntries() does today. If on the other hand we define it as async iterable<USVString, FileSystemHandle> (i.e. a map of names to handles) we would still get a values() method that does what getEntries() does today, but inaddition there would also be a keys() method (that just returns the names) and a entries() method that returns pairs of name+handle (a bit redundant since the handle already contains the name as well, but probably not the end of the world?).

Especially in that second case I don't think it makes sense to have entries() and getEntries() methods that return somewhat different things, so then I'd just drop getEntries() (with values() being its replacement). In the first case I suppose we could keep getEntries() as an alias for values(), but that still seems potentially confusing...