Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
quickjs-emscripten
Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
foal-ts-monorepo
Boilerplate for building a volatility-based system using Foal for the server and Create React App for the client
-
-
-
-
-
-
Bumble-Asteroids
An asteroids like game built with the Bumble framework and using Entity Component System
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Redux-sagas[0] makes great use of generators. I found it a fantastic tool, if you're already in the redux ecosystem, and have an application that sprawls enough to benefit. It's great when you have to manage multiple process lifecycles. A single "saga" can represent the entire lifespan of a session in just a few lines of code, a socket or similar long-lived process, with clear code branches to shorter-lived handlers or other sagas for the details.
The downsides are:
- a quirky syntax that needs learning, and is of the "loose with semantics" style - like Rails-eque REST's play with HTTP methods
- it's hard to test (despite what the documentation claims). It's highly declarative, and such code seems hard to test.
[0] http://redux-saga.js.org/
Easily done with Ix:
https://github.com/ReactiveX/IxJS/blob/master/docs/asynciter...
You can use One Weird Trick with generator functions to make your code "generic" over synchronicity. I use this technique to avoid needing to implement both sync and async versions of some functions in my quickjs-emscripten library.
The great part about this technique as a library author is that unlike choosing to use a Promise return type, this technique is invisible in my public API. I can write a function like `export function coolAlgorithm(getData: (request: I) => O | Promise): R | Promise`, and we get automatic performance improvement if the user's function happens to return synchronously, without mystery generator stuff showing up in the function signature.
Helper to make a function that can be either sync or async: https://github.com/justjake/quickjs-emscripten/blob/ff211447...
Uses: https://cs.github.com/justjake/quickjs-emscripten?q=yield*+l...
But createApi, as provided by RTK Query API, makes this quite a bit harder, or so it seems to me at least. How would you wrap createApi to provide such a functionality for every fetch by default?
[1]: https://github.com/kubeshop/testkube-dashboard
[2]: https://github.com/kubeshop/testkube-dashboard/tree/main/src...
For a concrete example, Relay uses them to garbage collect data in an asynchronous fashion. If an update is detected during the course of a gc, it is aborted.
https://github.com/facebook/relay/blob/main/packages/relay-r...
I used generators to increase the performance of bitstream parsing by several orders of magnitude over using a promise based system
https://github.com/astronautlabs/bitstream#generators
What's weird is that I still firmly believe that sagas is one of the sanest ways of organizing an application. I built a sort of boilerplate project that shows how I use it[1] but the TL;DR is that I can wrap all of my functionality into nice little sagas and manage the state very easily with lenses. Handling data fetching isn't too complicated either [2] but I'm also not doing any sort of fancy caching in this example.
[1]: https://github.com/MCluck90/foal-ts-monorepo/blob/main/app/c...
I found async generators to be handy while porting a C Prolog interpreter to WASM/JS. A `for await` loop is a natural way to iterate over query results, and as a bonus you can use `finally` within the iterator to automatically clean up resources (free memory). There are ways for determined users to leak (manually iterating and forgetting to call `.return()`) but I've found that setting a finalizer on a local variable inside of the generator seems to work :-). I can't say manual memory management is a common task in JS but it did the trick.
The generator in question, which is perhaps the gnarliest JS I've ever written: https://github.com/guregu/trealla-js/blob/887d200b8eecfca8ed...
I use generator coroutines pretty extensively in my game framework. It makes for some clean cooperative code that’s fun to write.
https://github.com/jbluepolarbear/Bumble
There's an active proposal which would let you do exactly that, going for stage 3 (ready for implementations) at the end of the month: https://github.com/tc39/proposal-iterator-helpers
I'm 1000% with you on this. If you're dealing with a bunch of operations that need to happen in a very specific order, there's really nothing else out there that comes close. I'm able to look at saga code I've written months (or years!) ago and figure out what's going on in a short amount of time without having to jump around.
I used sagas pretty heavily in an app I built to transfer data between Clockify and Toggl, which required that data be fetched/loaded into state in a very specific order[1]. You can't be sagas for clarity.
[1]: https://github.com/mikerourke/transfermyti.me/blob/main/src/...
Yeah, it’s fairly stable for what I use it for. I mainly use it for game jams and have done a few professional projects with it. Here’s an asteroids game I made with the framework work: https://github.com/jbluepolarbear/Bumble-Asteroids