-
-
Notifications
You must be signed in to change notification settings - Fork 35.4k
stream: add a non-destroying iterator to Readable #38526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
e21ad8d
87f5316
468f9ea
4bb108b
f939af2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1506,13 +1506,67 @@ async function print(readable) { | |
| print(fs.createReadStream('file')).catch(console.error); | ||
| ``` | ||
|
|
||
| If the loop terminates with a `break` or a `throw`, the stream will be | ||
| destroyed. In other terms, iterating over a stream will consume the stream | ||
| If the loop terminates with a `break`, `return` or a `throw`, the stream will | ||
| be destroyed. In other terms, iterating over a stream will consume the stream | ||
| fully. The stream will be read in chunks of size equal to the `highWaterMark` | ||
| option. In the code example above, data will be in a single chunk if the file | ||
| has less then 64KB of data because no `highWaterMark` option is provided to | ||
| [`fs.createReadStream()`][]. | ||
|
|
||
| ##### `readable.iterator([options])` | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just a thought: does this have to be in a new method rather than adding a parameter to the existing
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm -0 on naming. I prefer a new method as the
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It doesn't feel right to me if the user has to call
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not really, all the standard says it this method is called with no argument (https://tc39.es/ecma262/#sec-getiterator). The standard gives a clear rule for the returned object (https://tc39.es/ecma262/#sec-asynciterable-interface), but not for the function signature. I personally don't feel strongly either way.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd prefer the separate method. The key issue with extending standard-defined APIs is that it makes reasoning about the portability of code far more complicated. A separate method makes it clear. That said, the behavior of the two can be identical such that
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, the reason that one doesn't call the other is because of legacy streams and |
||
| <!-- YAML | ||
| added: REPLACEME | ||
| --> | ||
|
|
||
| * `options` {Object} | ||
| * `destroyOnReturn` {boolean} When set to `false`, calling `return` on the | ||
| async iterator, or exiting a `for await...of` iteration using a `break`, | ||
| `return` or `throw` will not destroy the stream. **Default:** `true`. | ||
| * `destroyOnError` {boolean} When set to `false`, if the stream emits an | ||
| error while it's being iterated, the iterator will not destroy the stream. | ||
| **Default:** `true`. | ||
| * Returns: {AsyncIterator} to consume the stream. | ||
|
|
||
| The iterator created by this method gives users the option to cancel the | ||
| destruction of the stream if the `for await...of` loop is exited by `return`, | ||
| `break` or `throw`, or if the iterator should destroy the stream if the stream | ||
| emitted an error during iteration. | ||
|
|
||
| ```js | ||
| const { Readable } = require('stream'); | ||
|
|
||
| async function printIterator(readable) { | ||
| for await (const chunk of readable.iterator({ destroyOnReturn: false })) { | ||
| console.log(chunk); // 1 | ||
| break; | ||
| } | ||
|
|
||
| console.log(readable.destroyed); // false | ||
|
|
||
| for await (const chunk of readable.iterator({ destroyOnReturn: false })) { | ||
| console.log(chunk); // Will print 2 and then 3 | ||
| } | ||
|
|
||
| console.log(readable.destroyed); // True, stream was totally consumed | ||
| } | ||
|
|
||
| async function printSymbolAsyncIterator(readable) { | ||
| for await (const chunk of readable) { | ||
| console.log(chunk); // 1 | ||
| break; | ||
| } | ||
|
|
||
| console.log(readable.destroyed); // true | ||
| } | ||
|
|
||
| async function showBoth() { | ||
| await printIterator(Readable.from([1, 2, 3])); | ||
| await printSymbolAsyncIterator(Readable.from([1, 2, 3])); | ||
| } | ||
|
|
||
| showBoth(); | ||
| ``` | ||
|
|
||
| ### Duplex and transform streams | ||
|
|
||
| #### Class: `stream.Duplex` | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.