fetch: removal of redundant condition

[debadree25]

Removed a redundant condition as per the issue

Fixes: #1813

[ronag]

How is it redundant?

[ronag]

@KhafraDev what is byte sequence here, actually? I think the condition might actually be intended as something else.

[KhafraDev]

A byte sequence is a webidl term that doesn't really have a javascript representation -- at least, not a single one. The actual definition is "a sequence of bytes", which, for us, could mean 2 things: an array of bytes, or a Uint8Array.

For example, both could technically be a "byte sequence":

const byteSequence = [0x41, 0x42, 0x43] // ABC

const byteSequence2 = new Uint8Array([0x41, 0x42, 0x43])

An array isn't a valid body, and is converted to a DOMString (becoming 65,66,67) and a Uint8Array is handled in the ArrayBuffer.isView check as mentioned in the issue.

---

According to codecov, this condition is never reached (as expected).

[jimmywarting]

I was also confused what a byte sequence meant in the beginning when i started working on Blob.js polyfill and also fetch-blob. My earlier version of blobs was solo based on having a ArrayBuffer to back up all the data that it represent.

Later learned that byte sequence could meant anything that isn't a javascript representation.
And fyi file/blobs are not only made up by things stored in memory.
A blob part can be represented by a file on the user hard drive too.
it wasn't until a saw the 3rd slide in https://docs.google.com/presentation/d/1MOm-8kacXAon1L2tF6VthesNjXgx0fp5AP17L7XDPSM/htmlpresent that i truly started to understand what Blobs really are good for.
So when you slice a blob then all you are really doing is changing the read offset and the size property but keeps a references to the old blob so you know where you should start reading from and when you should stop reading.

So doing things like new Blob([ fileA, fileB ]) dose not mean that it will allocate any memory for both file a and b.
you just tell it to read stuff from fileA then start reading the content from fileB in one single stream.

the blobParts in blob constructor is also a byte sequence

chrome have a very nice design system of how their blobs are made up and how they work under the hood
https://chromium.googlesource.com/chromium/src/+/HEAD/storage/browser/blob/README.md

I have later gotten much more appreciation of blobs after that.

I have for example built a zip parser that only read the central directory at the end of a blob (zip), then figure out where the content of a file start/ends and then just simply slice the zip and hand it back. it's such a beautiful design that makes it possible to never ever have to read anything into memory. it's sooo browser/RAM friendly and also way much faster than any other zip reader.

[KhafraDev]

A byte sequence is a sequence of bytes

The byte type is a signed integer type that has values in the range [−128, 127].

... and to convert a value to a byte:

Let x be ? ConvertToInt(V, 8, "signed").

Correcting myself earlier: a Uint8Array cannot be a valid byte sequence. The only typed array that can be a valid byte sequence is an Int8Array.

The blobParts parameter is not a byte sequence. It allows Blobs, ArrayBufferViews (typed arrays and DataView), ArrayBuffer, and strings.

[jimmywarting]

Hmm, yea. you are right. blobparts isn't exactly a byte sequence, but they are turned into a byte sequences in the constructor.

guess that is what it means by: Set value’s underlying byte sequence to serialized.[[ByteSequence]].

https://w3c.github.io/FileAPI/#dfn-BlobPropertyBagMembers

1 Let bytes be an empty sequence of bytes.
2, 3 If element is a Blob, append the bytes it represents to bytes.

lite off topic but a fun discussion non the less.

[KhafraDev]

Yeah, everything is converted to a byte sequence:

const uint8 = new Uint8Array([0xFF])
const blob = new Blob([uint8])
const text = await blob.text()

text.charCodeAt(0) // \uFFFD