- From: juner <notifications@github.com>
- Date: Fri, 30 Jan 2026 01:36:27 -0800
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/issues/1359/3822766025@github.com>
juner left a comment (whatwg/streams#1359) @MattiasBuelens 😄 Fair point — grouping them back into a controller is certainly the obvious shape, and I agree that if this functionality exists, `ReadableStreamDefaultController` is a natural place for it. I think there may be two slightly different questions here, though: 1. *How do you obtain a controller?* (`withController()`, `withResolvers()`, or the existing constructor + underlying source hooks) 2. *What observable state does a controller expose once you have it?* (e.g. `closed`, `state`, etc.) My original motivation was mostly about (2): giving producers an explicit, synchronous way to observe completion, so they can deliberately avoid late enqueues without relying on try/catch, while still preserving the existing fail-fast semantics and backpressure behavior. Exposing something like `controller.closed` or a small `controller.state` enum would address that concern just as well, and arguably more cleanly, than hanging it off a separate “resolvers” object. That also avoids introducing a new conceptual surface if the information naturally belongs to the controller anyway. So yes — if the direction is to add observable completion state, putting it on `ReadableStreamDefaultController` itself seems like a very reasonable place to explore. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/streams/issues/1359#issuecomment-3822766025 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/streams/issues/1359/3822766025@github.com>
Received on Friday, 30 January 2026 09:36:31 UTC