-
-
Notifications
You must be signed in to change notification settings - Fork 972
Closed
Description
What would you like to discuss?
Hello,
Currently, the request body option can be, among others types, Generator / AsyncGenerator:
https://github.com/sindresorhus/got/blob/a7b5aec57a0245cafbd21696d52cd6bd6c95628a/source/core/options.ts#L1306-1311
These bodies are used like anything implementing the Iterable / AsyncIterable protocol, via a simple for await..of loop:
Lines 969 to 980 in a7b5aec
| } else if (is.generator(body) || is.asyncGenerator(body)) { | |
| (async () => { | |
| try { | |
| for await (const chunk of body) { | |
| await this._asyncWrite(chunk); | |
| } | |
| super.end(); | |
| } catch (error: any) { | |
| this._beforeError(error); | |
| } | |
| })(); |
So, the question is: Why not using the more generic Iterable / AsyncIterable instead of Generator / AsyncGenerator, as the differences should be very minor? Is there a limitation somewhere, preventing to do that?
Another benefit would be supporting the web ReadableStreams directly, with no prior conversion.
Checklist
- I have read the documentation.
Metadata
Metadata
Assignees
Labels
No labels