Re: [w3c/FileAPI] Streams are hot, FileReader.readAs____ is not (#40)

So I've been sort or arguing against things like this in the past, primarily because it doesn't seem like adding more methods etc really helps much for the API when you can already achieve pretty much anything by calling `new Response(my_blob).body`, `.arrayBuffer()`, `.text()` etc to read a blob with a nicely promisified and or streamified API. But that doesn't feel very satisfying. The `Response` wrapping trick kind of feels like a hack, and especially as long as `FileReader` still exists as well, it isn't very discoverable.

So what to do about this. If I squint hard enough it sort of seems to make sense if a `Blob` would just implement the [`Body`](https://fetch.spec.whatwg.org/#body) mixin. That way we get all its methods "for free". The main problem with that is that `Body` by design can only be read from once. This is particularly the case for the `body` and `bodyUsed` attributes. We could of course still have the same API, but with a slightly different behavior where `bodyUsed` would always return `false`, and `body` would return a new `ReadableStream` every time it is accessed. Not sure how weird that would be (and it might require some patching of the algorithms in fetch to make that happen).

The alternative would of course be to not inherit from the `Body` mixin, and instead replicate most of the interface ourselves, with something like the proposed `toStream()` method rather than the `body` attribute that the `Body` mixin has. That still seems better than just relying on the `new Response(...).bla()` hack, but also feels somewhat less satisfying, since we're essentially mostly duplicating an existing interface...

So what do people think? Shoe-horn in `Body` with potentially slightly different semantics (i.e. being able to read the blob multiple times), or just add all the methods of `Body` without actually implementing `Body`?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/40#issuecomment-461221641