4 ms·
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
by guest124678 8y ago
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.
- daxterspeed 8y agoBoth 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/Reference/Statements/for-await...of https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Example of this syntax in practice: https://jsbin.com/folotu/edit?js,console https://jsbin.com/folotu/edit?js,console
- loige 8y agoI 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.
- haskman 8y agoYou 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 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.
- zawerf 8y agoYou 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.
- jondubois 8y agoWhat 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-stream#consume-a-filtered-stream-using-an-async-generator https://github.com/SocketCluster/writable-async-iterable-str... Worked perfectly for me on Node.js 10.
- loige 8y agoReadable-streams v3 (https://www.nearform.com/blog/welcome-readable-stream-3/ 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_asynciterator https://nodejs.org/api/stream.html#stream_readable_symbol_as...
- jondubois 8y agoI 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.