Backends for the File and Directory Entries API and the File API

[Pistonight]

Rationale

FileSystemAccess API is great but poor firefox users don't get it :(

In the past I built a web-editing experience where users can select a directory and have bi-directional syncing between content in the web editor and local content. This means user can edit in the web editor and their changes are periodically write-back to the disk, and if they edit the content on the disk, it's also periodically polled from the browser.

I ended up building 2 fallbacks in firefox: DataTransferItem.webkitGetAsEntry and the classic <input type="file" webkitdirectory="true">. The first implementation allows reading the latest content but does not allow writing. The <input> only allow stale content (as all of it is uploaded when selecting the directory). (BTW, the relevant code is here: https://github.com/Pistonite/pure/blob/main/OLD/fs/FsOpen.ts#L152C1-L153C1 )

This experience isn't optimal - firefox users get different behaviors if they drag'n'drop (supports polling but not write) vs. clicking an "open folder" icon (no polling or write). However it was still a little bit helpful in driving adoption compared to a "hey go download chrome" screen.

I found this project today and I think this is really cool - especially backends like SingleBuffer, InMemory, WebStorage which I think could really be helpful in some of my projects in the future. It would be nice to also be able to use the WebAccess backend for all browsers so I can use this library for all filesystem-in-browser needs

API Proposal

WebEntry backend which uses https://developer.mozilla.org/en-US/docs/Web/API/DataTransferItem/webkitGetAsEntry
this backend will not support writing
WebFiles backend which uses https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/files
this backend will not support writing and read calls will not read the latest content from disk

(Also If I remember correctly, webkitGetAsEntry actually doesn't work in Chrome - maybe a isSupported API is needed, but that can also easily be done by downstream)

Additional context

No response

[james-pre]

Hey @Pistonight!

I've considered the File and Directory Entries API in the past, and while a backend could be implemented I reasoned at the time that a backend's usefulness would be somewhat limited on account of the API only supporting read operations.

The "regular" File API is also somewhat limiting since it doesn't support directories and can only read.

I would accept PRs if someone added these backends but I don't see myself implementing them unless there is significant user demand for it.

FileSystemAccess API is great but poor Firefox users don't get it :(

Yeah Firefox only has the origin private file system exposed by navigator.storage.getDirectory(). It would be great if it could support showDirectoryPicker()/showOpenFilePicker()/showSaveFilePicker()/etc. as these function are part of the spec. In this case Firefox just doesn't support the functions that should be there.

I'm also hesitant in general to implement backends that are built around the behavior of a cross-platform API exhibited on a single platform, rather than conforming to specs. I took a look at the code you referenced and all I can say is that using these APIs can be very convoluted.

Also in the code you referenced I recommend just using ZenFS' and kerium's APIs instead of wrapping them since it significantly reduces your maintaince burdon.

In any case I'll leave this open in the event some mad lad wants to give implementing these backends a go.