Upcoming, a new & simplified implementation of https://thi.ng/csp (currently still only on a feature branch[2]) for building blocks for Communicating Sequential Processes.
Also still WIP only, async iterable support for https://thi.ng/rdom, i.e. in the same way as rstream subscriptions, such async iterables can soon be directly embedded as component/element bodies or attribute values and then perform pinpointed DOM updates each time their value changes...
As I said, async all the thi.ngs...
[1] h/t @sjb3d for an ancient tweet with a similar sentiment & outcome :)
[2] The CSP package too was somewhat deprecated (for similar reasons) and a while ago I added another alternative CSP implementation via https://thi.ng/fibers, but that package too might see some more refactoring/simplifying by switching to async generators...
@toxi@sjb3d was it so silent? 😅
These async transducers are generators and work a bit like co-routines right? I did not fully look into it, but do you use them within i.e. rstream and rdom to keep a responsive interface? So instead of blocking render() with an expensive .map(…) you could do .next() .next() .render() .next() while i.e. checking fps?
@made Transducers are not generators, but work with them (or more concretely: transform values obtained from generators). The https://thi.ng/transducers-async package provides 3 sets of functions: async generators (to produce or compose inputs), async transducers (composable value transforms) and async reducers (i.e. to collect transformed values). There's also another set of functions (I call them "evaluators") which allow you to use these transducers & iterables in different ways. Aannnd, also have to point out that you can also use all of the 150+ "normal" (synchronous) transducers & generators from the https://thi.ng/transducers parent package with these new async versions (but NOT the way around)...
For UI purposes (just one of many other intended use cases), the idea is that you can pop an async iterable (with or without transducers) anywhere in your https://thi.ng/rdom component tree, and depending on where it's used, any future values produced by that iterable will be directly reflected in the DOM, exactly like done with rstream subs already... (very sorry, but I'm not quite getting your .next().next()... part of the question, let's maybe take that to GH?)
Ps. In general, there's now quite a bit conceptual overlap between some of these packages (mainly due to historic reasons/factors, e.g. lack of proper async iterator support in browsers/node when I started working on many of these things) - I'm trying to consolidate some of this, but it will take a while...
Add comment