Closed billiegoose closed 6 years ago
I just realized that I introduced the only occurrence of a Promise in the codebase, aside from one in the DropboxFS test factory. There might be a reason for that. Also, that would be awkward to only have one API call that used Promises. I may have been over-thinking with this PR.
I've avoided using Promises for the following reasons:
fs
functions!So, I think I will close this and let users of the library choose whether or not they want to "promisify" the portions of BrowserFS they use.
Sounds good to me! I was just getting carried away.
Currently,
BrowserFS.configure()
is a little awkward if you are not usingBrowserFS.install(window)
. You end up with something like:Then it gets more awkward if you have multiple modules acting on the file system, because I don't think you want to call
BrowserFS.configure
once in each module. So what I've been doing in my project is wrapping the file system as a const Promise like this:so I can use it like this:
This PR would make the callback to
BrowserFS.configure
optional. If it detects there's no callback, instead of returningvoid
it returns aPromise<FileSystem>
. This simplifies the weird boilerplate in my example 'filesystem.js' above so it looks like this:If you like the idea I can try to add a test case and update the documentation.