Re: [whatwg/streams] ReadableStream.prototype.arrayBuffer() (#1019)

> If we do add these directly to ReadableStream.prototype then they should only work on byte-oriented streams.

If the streams are passing strings that should be fine too for `json` and `text`, right? Particularly if they're internally buffering rather than returning the next chunk of valid data

> Honestly, the more I think about it, the more I'd really prefer the ...fromAsync(...) pattern for multiple things...

From an implementer perspective, it sounds nice.

From a JS developer perspective, I have trouble imagining developers prefer this over `.text()`, `.bytes()`, `.json()`. 

My gut here is that most JS developers would prefer the idea of both, but probably 98% of all usage would be one of `.text()`, `.json()` `.arrayBuffer()` `.bytes()` rather than the `Constructor.fromAsync(iterable)` variant. 

People are used to `fetch`-like `.text()` instead of `fromAsync` and `fromAsync` is more complicated to explain. 

This chain of reasoning is more complicated:

> 1. it's a `ReadableStream`
> 2. therefore it's an async iterable
> 3. therefore to get the value as a `String` you call `String.fromAsync`

Compared to:

> 1. call `.text()` on the `ReadableStream`

---

> if we can't specify the text encoding

Isn't there precedent for defaulting to UTF-8? Or is that Windows-1252? 


> For text encoding, the pattern is pretty natural:
> `const str = await String.fromAsync(readable.pipeThrough(new TextDecoderStream("...")));`

I think this pattern composes well, but would only feel natural to developers who understand a lot of streams and spec authors. It would feel complicated for less experienced developers

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1019#issuecomment-2017010825
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1019/2017010825@github.com>