Hacker News Reader

Comment by guest124678 | Hacker News Reader

The next step I would have shown if I wrote this article, would have been to tell reader that JS generators as they are now, do not work with async / wait.

As long as you have some simple Fibonacci interview question they look nice to show off, but when you want to use them for real like return some paginated data from server as on going iterator, then current JS generators cannot be used.

This makes js generators limited for any real usage, given JS IO is async.

View on HN

Both async generator functions and async iterators have been in the pipeline for a while. The proposed, and currently implemented syntax in Firefox and Chrome is `for await ... of`[0]. Creating an async generator function is as easy as `async function* functionName`.

[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Example of this syntax in practice: https://jsbin.com/folotu/edit?js,console

I have another article in mind to approach this topic. Also event emitters and streams might be other useful tools of the trade when you have to deal with asynchronous stuff.

You might be interested in a slightly unusual UI framework I wrote that heavily focuses on async generators to define the UI - https://github.com/ajnsit/concur-js.

The idea is that a UI "Widget" is a sequence of UIs (which themselves can be Widgets) generated asynchronously (say when a UI event fires).

A sample widget -

    async function*() {
      // Show a clickable button.
      // All processing is async, this will conceptually block until button is clicked.
      yield* <button onClick>Click me</button>
      // Button was clicked, show text
      yield* <div>Button was clicked!</div>
    })

It uses React and VDOM to diff the UIs generated and update the page slightly more efficiently. As you can see, it also provides JSX support (by overriding createElement calls).

The Widgets themselves can be easily composed, and the entire thing is designed to be extremely easy to get started with. The README on github has more information.

What do you mean they can't be used? I wrote a stream library with an example of how to filter using an async generator here: https://github.com/SocketCluster/writable-async-iterable-str...

Worked perfectly for me on Node.js 10.

Readable-streams v3 (https://www.nearform.com/blog/welcome-readable-stream-3/) allows you to use async iterators to process streams (`for...await...of` syntax).

This is actually in Node.js current, check out stream docs: https://nodejs.org/api/stream.html#stream_readable_symbol_as...

I did consider using the Node.js streams at one point but they support a lot of legacy edge cases and are more relevant for I/O than just a simple event stream (which was my use case). My stream library is less than 100 lines of code and only supports asyncIterator interface; also, it supports multiple concurrent consumers; each consuming at its own pace.

You can do a generator returning promises.

It's actually preferred over async/await in the frontend world in libraries such as redux-saga and mobx flow. One advantage is that you can cancel the iteration early.

Reply on news.ycombinator.com