Re: [whatwg/streams] Add a flag to determine wether a ReadableStream is disturbed or cancelled (#1025)

It's normal for trusted libraries to hook into internals, it's not ok to make developer rely on some heuristics to determine what happened with the code. 

Consistency and reduced complexity of web platform is itself the best use-case. But moreover current API has inconsistency in design and the first consumer of it – the Fetch API – is an indicator of the problem.

So developers couldn't check validity of streams in constructors, whaat will make API design unnecessary complex: developer should create a class instance, then run some async method to check if everything is fine and constructor arguments are valid.

And the main problem with this solution is redundant delays and memory usage. Here it is [the solution](https://github.com/nodejs/node/issues/39627#issuecomment-897013552) by @domenic in node's repo:

```js
async function isReadable(reader) {
  let readable = true;
  reader.closed.then(() => { readable = false; }, () => { readable = false; });
  await Promise.resolve();

  // If the stream was closed or errored then the closed promise would have settled by now and updated readable.
  // If not then it's readable.
  return readable;
}
```

It creates 3 promises and 3 jumps over event loop stack just to determine stream state. Moreover function scope with its boolean, function and one of this promises will live as long as stream is not closed and thus would hold memory. In the case of high loads, this will be memory pressure out of nowhere. This check should be made in a single synchronous call.

As a conclusion, current API design:
a. overcomplicated,
b. brings redundant load,
c. distribute complexity over multiple environments, which are Webkit, Firefox, Chromium, Node, Deno, embeddable JS and other JS environments.

So the question here is what the use case for making Stream status check asynchronous?

@domenic Please, reopen this issue. Also could you answer on the question above or provide a link where I could find such answer,  because it seems like you are the one who's responsible for the API and all the decisions. I don't want to spend anyone time, but the issue isn't solved.


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