type of Chunk.value

[bblfish]

Hi,

how is one meant to know what the value of a chunk is going to be? Does that depend on the function that returns chunks? The specification says in ¶2. Model:

A chunk is a single piece of data that is written to or read from a stream. It can be of any type; streams can even contain chunks of different types. A chunk will often not be the most atomic unit of data for a given stream; for example a byte stream might contain chunks consisting of 16 KiB Uint8Arrays, instead of single bytes.

By printing out the value I seem to have at one point found that it was an Array of bytes ( but I am no longer sure), at another time a Uint8Array which is a form of TypedArray.

If one can always treat the chunk.value as a Uint8Array would it not be best to state that this is what it returns?

[domenic]

It is whatever type the creator of the stream wants it to be.

[domenic]

It can be multiple types in the same stream too. Each chunk can be different, if that is what the creator wants.

[bblfish]

Ok so that means that functions returning a Chunk should specify what the exact type of the Chunk is I suppose. I am using the Fetch API's fetch method which returns a Promise of a Response, which contains a body which is a ReadableStream.

Presumably they should state in their documentation what the type of the chunks returned by the ReadableStream is right? ( It would make it a bit easier to read the docs and use the APIs ).

Hmm it looks like the Response.body method says:

A body is a byte stream. It has an associated transmitted which is an integer and initially 0, length which is an integer and initially 0, and error flag which is initially unset.

So I suppose that means the content of the chunk contains bytes, but it is not clear that this means that all chunks will be Uint8Arrays

[domenic]

https://fetch.spec.whatwg.org/ may help clarify:

Enqueue a Uint8Array object wrapping an ArrayBuffer containing the result of reading response's body into stream. If that threw an exception, run the following subsubsteps and terminate these substeps:

[tyoshino]

Hmm it looks like the Response.body method says:

https://fetch.spec.whatwg.org/#concept-body you've pointed in this sentence is not Response.body. It's a concept body associated with a concept request or a concept response.

You should look at https://fetch.spec.whatwg.org/#dom-response-body which actually specifies what the JavaScript interface Response.body is. It leads you to the text @domenic just mentioned above.

(/cc @yutakahirano)

[bblfish]

Ah I see there is a note:

This might become a ReadableByteStream object. While the type might change, the behavior specified will be equivalent since the hypothetical ReadableByteStream object will have the same members as the ReadableStream object has today.

So I suppose that's what I was missing, as I imagine that would state that a ReadableByteStream is a streams whose chunks contain Uint8Arrays.

That's close to my suggestion. Though you'd avoid having to create new types of objects by developing a generics style notation for the documentation.

[tyoshino]

Though you'd avoid having to create new types of objects by developing a generics style notation for the documentation.

ReadableByteStream is not just a ReadableStream with Uint8Array chunks in it. ReadableByteStream has more functionality that is not specified in ReadableStream to allow efficient handling of bytes (though we're discussing if we can merge them at #379).

[domenic]

IDL Is not for documentation (nor are specs in general, really). MDN is probably a better place for that.

[tyoshino]

Ya

[bblfish]

@tyoshino in that case you have

ReadableByteStream<T> extends ByteStream<T>

@domenic as a user I have no idea how up-to-date the MDN documentation is. I'd rather go to the specs themselves.

[domenic]

@bblfish in that case you'd better learn how to read specs, despite them not being written as documentation for users.

[bblfish]

@domenic I am doing my best, and I am sure you are too.
Note that the people reading these specs is what allows us to find bugs in them, such as whatwg/fetch#164 . So the easier you make it to be read by good developers, the more will read them, and the better those specs will be. see: Linus' law: "Given enough eyeballs, all bugs are shallow"