Async iterators
Closed this issue · 4 comments
Hey,
Async iterators are a stage 3 proposal for asynchronous pull streams (link) with a v8 implementation arriving very soon.
Async iterators and the new for await... of
loop are coming our way. I'd like to bring that up for discussion for several reasons.
- This is likely the last chance Node has to have a say on that spec. Personally I've went through the spec with Node's interests in mind and while some things (like postmortem) are blocked on promise tooling the spec looks very clean and usable to me. I think it'll make users' lives easier.
- A new
Symbol.asyncIterator
is introduced. I believestream.Readable
should supportSymbol.asyncIteator
which would allow it to be iterated withfor...await
. Note that since async iterators are pull streams backpressure sounds fairly easy to do. cc @nodejs/streams
As an example of what asyncIterator
might behave like, you could iterate on data
events. For example here's a classic "reading data from a request naive example".
let body = '';
for await(const data on req) body += data;
const parsed = JSON.parse(body); // note that we can let errors propagate, since we're in an async fn
console.log("got", parsed);
@benjamingr as recent events played for the multiple inheritance, I have nothing opposing Symbol.asyncIterator
where it is available. However, it should not impact performance of existing code in any way, as meta-programming with Symbol recently slowed instanceof
of 100x in node v7.
From an implementation perspective, there are probably some lines of code involved.
However, is this a CTC issue? Can we work on this through issues/PR?
@benjamingr it would be good if you could pass by the next stream wg meeting, nodejs/readable-stream#252. Maybe we can open an issue there and we can start discussing it before.
However, it should not impact performance of existing code in any way, as meta-programming with Symbol recently slowed instanceof of 100x in node v7.
This would just mean adding a Symbol.asyncIterator
to the prototype and should not incur a performance penalty. I have high hopes that eventually it will be fast enough so it can be used in place of .on('data'
in "tight" scenarios.
I'll open a separate issue for Symbol.asyncIterator
in the readable-stream repo. This issue was more about giving the CTC and collaborators a chance to discuss the feature as a whole before it is "forced upon us" like promises were (so if there is a big objection to the async iteration spec conceptually - we will catch it in time). I apologize if I made it sound as if this issue was focused on Symbol.asyncIterator
.
This has been addressed in nodejs/readable-stream. Thanks everyone!