fs: add Blob methods to FileHandle

[aduh95]

Adding .text() and .arrayBuffer() methods to FileHandle to make it closer to W3C File interface.

I'm proposing to add .stream() in #40016, and I don't think we want to have the .slice() as it would require a synchronous read of the file.

[ronag]

toUSVString?

[ronag]

https://fetch.spec.whatwg.org/#body-mixin?

Ah, I see you want to implement File. The webstandard is a little messy :/ .

[ronag]

and I don't think we want to have the .slice() as it would require a synchronous read of the file.

Why does it need to be synchronous? Blob is asynchronous.

[ronag]

I think @jasnell is planning on implementing File so maybe there is some overlap here?

[aduh95]

I don't feel strongly about it, Body may work indeed (we won't be able to have .formData() I think, but I don't think anyone is asking for it anyway). File seems like a more logical go to for FileHandle, but I'm not married to it.

Why does it need to be synchronous? Blob is asynchronous.

Can I create a Blob without reading the file synchronously? How would I do that? .slice() is synchronous, it must return a Blob synchronously.

[ronag]

Can I create a Blob without reading the file synchronously? How would I do that? .slice() is synchronous, it must return a Blob synchronously.

You can create it synchronously but it cannot be read synchronously. So you just create a new instance that has an asynchronous read operation, i.e. just create a new file handle with an start + len offset.

[aduh95]

Parts of File that wouldn't make much sense for FileHandle:

• readonly attribute DOMString name: that would return empty string, not very useful.
• readonly attribute long long lastModified: we would either need to call statSync, or return Date.now().
• readonly attribute unsigned long long size: we would either need to call statSync, or return 0.
• readonly attribute DOMString type: that would return empty string, not very useful.
• A File object is a Blob object: Making FileHandle extend Blob doesn't seem reasonable, nor useful.

Given that, I think it's fair to assume we don't want FileHandle to 100% match the File interface, and it's OK to leave out that .slice() method.

My take on this is we should try to match the web spec where it makes sense and deviates where it makes sense, like we do for the Worker implementation.

[Jamesernator]

Given that, I think it's fair to assume we don't want FileHandle to 100% match the File interface, and it's OK to leave out that .slice() method.

I agree with this, although it may be desirable in future to have a .toBlob() that returns an actual Blob. Unlike files which are unstable over time, .toBlob() would return a (promise for) an immutable snapshot (possibly as a File with lastModified and such). Admittedly this would be considerably better if more file systems supported copy-on-write as it wouldn't involve a full copy of the file (at the moment only BTRFS and ZFS support it).

[jasnell]

To be honest, I'm not sold on the idea of adding these methods to FileHandle at all. Alternatively, we can add FileHandle to the list of types accepted by the stream/consumers utilities, which would likely be more consistent.

[Mesteery]

It would be a bit inconsistent/weird to have to import consumers from stream/consumers to use them on fs.FileHandle, no?

[aduh95]

If #40009 lands, I'd be also more inclined to stick to stream/consumers: one could do await blob(fileHandle.createReadStream());.

[jasnell]

To make it explicit, I'd prefer not to do it this way. Let's use stream/consumers

[aduh95]

Closing as there doesn’t seem to have a need for this actually.