-
Notifications
You must be signed in to change notification settings - Fork 65
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
Should choose
always return an array?
#25
Comments
Some developers will find the "sometimes returns single, sometimes returns array" pattern confusing and expect that if Is having a separate (Which is to say: having simple |
I don't think people would expect the return type to be different based on how many files were selected, as that would require additional code to handle both cases. In my experience using the chrome.fileSystem api, the correlation of the return format to the multiple option is sufficiently clear. |
I came here to file a similar issue, which is that the mismatch of plural Two options in addition to the status quo:
I think always returning an array might be my favorite, but this is bikeshedding for sure. |
Copy-pasting my comment from #146 before I realized it was a duplicate of this issue: I have no strong opinions on naming here. Originally I had chooseFileSystemEntries always return its results as an array, even if As an aside, I'm not a big fan of the It does seem like it might be cleaner to have separate methods with well-defined return types instead. One extreme might be to have 3 (or 4) different methods for all the different possible return types, i.e. separate |
My feedback:
|
What if we instead replaced multiple/allowMultiple with limit? limit=1 You always get an array and you get a new feature out of it. 1 or infinity could be the default. |
I don't think a limit is something system provided file pickers usually support. Of course we could require browsers to implement their own file pickers, but that still would result in something that behaves in a way users might not be familiar with. I think I'm leaning towards separate methods as well. That also has the benefit that its clearer which options are applicable to which methods (i.e. "accepts" only for file dialogs). |
@kenchris and I discussed during our VF2F - and we both concluded that polymorphism in this context is an interesting (in an en_UK sense) design decision. Our two cents would be to provide two separate methods or skip the singular case optimization and return a sequence with the cardinality of one and provide a single method. (Both of us prefer a single method which returns a sequence, but the choice is up to you.) |
Also in the multiple files chooser, the user can end up just selecting a single file which would then just return a sequence of one single file. If the dev knows that there will ever only be one file selected, then they can just do files[0] or similar, and if they are prepared to handle multiple files, that code will also work for a single file. This is also consistent with input type=file |
Always returning an array, even if const [selectedFile] = await window.chooseFileSystemEntries({
type: 'open-file',
multiple: false,
}); |
* Change the API surface for getting native file system handles. Rather than having one method do three different things, just have separate methods for all three options. Also aligns (mostly) with the file handling API in how accepted file types are specified. This fixes #170, fixes #134, fixes #133 and fixes #25.
@mkruisselbrink On the web developer side, this API would not be desirable. It is strongly desirable to be able to select files and directories simultaneously. It also seems to make sense to have a single consistent API, with a consistent return type. |
What do you mean with this? You want to be able to show a dialog that lets the user select both files and directories? That is not something most systems native file/directory pickers currently support, and I haven't really heard of any use cases that would need that either. Usually opening a file or opening a folder are very separate flows in applications that I am familiar with. Could you elaborate a bit more with what use cases this would allow?
The major reason for splitting this up in multiple methods is to have methods with consistent return types. I.e. not have one method where the return type changes depending on the passed in arguments. With separate methods the return type of each method is always the same, making it much easier for static type checkers to validate code being valid. |
In the current strawman proposal the
choose
style API returns a single handle ifmultiple
is false (or not specified), and returns a sequence ifmultiple
is true (even if in that case only a single file was selected). Would it be more/less confusing if the API always returned an array?The text was updated successfully, but these errors were encountered: