-
-
Notifications
You must be signed in to change notification settings - Fork 52
Add Symbol.asyncIterator to iterator #235
Comments
I've added an alternative take on this. 16e36ee in theory it will just not do anything on older node, but can still be parsed as it manually making the async iterator object. I'll guess we'll see shortly if it passes node < 12 tests. |
IMO that much boilerplate code is just not worth it and a sign that async iterators hadn't matured yet. Async generators make it so much cleaner and digestible, similar to what |
true; yes - generators are nice, but there is (or at least was) a major short coming with the generator approach if you absolutely need to clean-up: you don't know if the user breaks out or not.. i.e.
My solution (and answer to the SO) is was to hack the |
I actually gave up on using async iterators last year - I've gone to rxjs for everything at work now. Its just more consistent as you absolutely know when something unsubscribes. |
if you absolutely want to use a generator you could maybe do it like this (your generator code from other pr) AbstractIterator.prototype[Symbol.asyncIterator] = function(){
let it = (async function * generate() {
try {
var kv
while ((kv = await this.next()) !== undefined) {
yield kv
}
} finally {
await this.end()
}
}).bind(this)()
it.return = function(){
this.end();
}.bind(this)
return it;
} btw: I don't think its a case of not being mature either; this problem is in sync generators too from es6. |
That's terrible. Good to know, thanks |
Closes #235. Supersedes #338, which was just a proof of concept and we've since dropped support of legacy runtimes (Level/community#98) which now allows us to use async generators across the board.
Background and use cases in Level/levelup#477 and Level/levelup#491.
The text was updated successfully, but these errors were encountered: