Change the remove operation to be part of a directory handle.#55
Conversation
pwnall
left a comment
There was a problem hiding this comment.
LGTM w/ one nit.
Thank you for the quick follow-up on the issue!
| Promise<sequence<USVString>?> resolve(FileSystemHandle handle); | ||
|
|
||
| Promise<void> removeRecursively(); | ||
| Promise<void> removeEntry(USVString name, optional FileSystemRemoveOptions options); |
There was a problem hiding this comment.
While I personally like remove, the web platform seems to have settled on delete for this operation.
So, WDYT of delete, or deleteEntry?
Also fine to leave the name as-is and let the TAG decide when we submit a review.
There was a problem hiding this comment.
I think I'll leave as is for now. Which web platform APIs were you referring to btw? I guess CacheStorage indeed uses delete, but for example DOM has removeChild and removeAttribute
Before each handle had a remove method that would remove the entry represented by the handle. This changes it to instead have a removeEntry method on a directory handle that will remove a child of that directory. This means it is no longer possible to delete an individual file or directory without having a handle to its parent, but otherwise feels like a slightly nicer API shape to me.
1a2c82b to
bcd36d8
Compare
|
I was thinking primarily of whatwg/cookiestore#46. I agree we shouldn't block the API improvements in this PR on the name, though. I'll open an issue to track the name and let folks chime in there. |
Before each handle had a remove method that would remove the entry
represented by the handle. This changes it to instead have a removeEntry
method on a directory handle that will remove a child of that directory.
This means it is no longer possible to delete an individual file or
directory without having a handle to its parent, but otherwise feels
like a slightly nicer API shape to me.
This fixes#54