Consider renaming getDirectoriesAndFiles to fsitems or getFSItems

[jwatt]

"getDirectoriesAndFiles" has two problems that I see:

• The FileSystem API spec may at some point want to allow for things that are not files or directories. For example maybe symbolic links if they link to something that's under a Directory that's been exposed to the content.
• The name is 22 characters long which is an extra factor turning people off this new API relative to webkitdirectory.

Perhaps we could call it getFSItems (FS being short for FileSystem)? That's more generic and only 10 characters long, which is twice as long as "files" (even longer if you count the required parentheses for the function call), but hey, better than 22 (or 24).

CC @aliams @arunranga

[jwatt]

And is there any reason that this has to be a function to expose a Promise? Maybe it could just be a JS property fsitems. Only 7 chars! ;)

[jwatt]

Note that the need to do feature detection makes the length more annoying, since you end up with code like:

function onInput(input) {
  if (input.getFilesAndDirectories) {
    input.getFilesAndDirectories().then(...);
  } else {
    input.files
  }

and

  if (item.getFilesAndDirectories) {
    ... item.getFilesAndDirectories() ...
  } else {
    ... not a Directory, do File stuff ...
  }

[aliams]

I never really liked getFilesAndDirecotories because it was so lengthy. To your point about it being a property (e.g. fsitems), I think that could work, but I just wonder if it would be weird to have a property be a Promise. Do you know of any other API where this is the case?

[aliams]

One other thought I had was that methods allow you to defer the processing of the Promise until its been called. It might be a problem to have, for example, DataTransfer.fsitems since not all events using DataTransfer will particularly be interested in fsitems, but the Promise would have to be populated and ready to go when a developer asks for it. One way around that would be to not start processing the filesystem items until the fsitems is referenced, but that could potentially be a little strange.

[inexorabletash]

Re: "property be a Promise"

There are instances in Web Animations, CSS Font Loading, Streams, Service Workers. (Probably more, those are just some of the ones I found implemented in Blink so far.) Newish but not crazy.

But... are we talking about this on Directory, or HTMLInputElement, or both?

On Directory it makes sense assuming it is immutable, like File. But what happens if you call input.chooseDirectory() - the value returned by the attribute accessor would swap out for a new, as-yet-unresolved Promise, I guess? That feels a bit odd, but then again I proposed the same thing in https://github.com/inexorabletash/indexeddb-promises for cursors.

[aliams]

Thank you for confirming @inexorabletash.

I think your reasoning makes sense for why we might want to keep it a method for Directory. It may work best then to have HTMLInputElement follow that pattern of having a method instead of a property so that we have a homogenous API. For some background knowledge, the reason we named the method getFilesAndDirectories was so that it would make sense under the various contexts from which it could be called: Directory, HTMLInputElement, and DataTransfer.

[arunranga]

This change should be thought of in context of WICG/directory-upload/issues/33 (which is based on an event, willchange, suggested in WICG/directory-upload#11). Thoughts on that? It removes the promise-based API.