Skip to content
This repository has been archived by the owner on Dec 1, 2024. It is now read-only.

Add Symbol.asyncIterator to iterator #235

Closed
vweevers opened this issue Jun 16, 2018 · 6 comments · Fixed by #379
Closed

Add Symbol.asyncIterator to iterator #235

vweevers opened this issue Jun 16, 2018 · 6 comments · Fixed by #379
Labels
enhancement New feature or request semver-minor New features that are backward compatible

Comments

@vweevers
Copy link
Member

Background and use cases in Level/levelup#477 and Level/levelup#491.

@vweevers vweevers added the enhancement New feature or request label Jun 16, 2018
@vweevers vweevers added the semver-minor New features that are backward compatible label Mar 31, 2019
@MeirionHughes
Copy link
Member

MeirionHughes commented Jun 22, 2019

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.

@vweevers
Copy link
Member Author

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 async/await does for promises.

@MeirionHughes
Copy link
Member

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.

async function *(){
  yield 1; 
  yield 2; 
  yield 3;
}

for await (let item of source()){
   break;
}

My solution (and answer to the SO) is was to hack the return, which is even more boiler plate than simply rolling your own {next, return, error} object.

@MeirionHughes
Copy link
Member

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.

@MeirionHughes
Copy link
Member

MeirionHughes commented Jun 22, 2019

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.

@vweevers
Copy link
Member Author

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..

That's terrible. Good to know, thanks

vweevers added a commit that referenced this issue Sep 12, 2021
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.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request semver-minor New features that are backward compatible
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants