naivistic but async-enabled transducer (micro-)library
The transducer approach can be used to improve the 'ordinary' array map an filter operations that we know and love.
- by not having to create a new collection for each map/filter operation (this can improve efficiency with large collections, and is the motivating example in various blog posts, as well as )
- making it more convenient to use async functions in map and filter. This means that you
don't need to wrap your map result in
Promise.all. The goal in this case is to improve readability rather than speed (Two approaches are possible; either to wait for every promise, so items will be processed sequentially. The other is to start processing every input alement at once.)
There are two constructors
filter nothing special here
The basic interface is a function
tr_array which expects an array (or another type of iterable object) of
input values followed by any number of maps or filters.
It traverses (hence the
tr_ prefix) the input collection, passes each element through the provided
stages, and returns a new array with the results.
const tr_array map filter =numbers = 1 2 4 5 6 7 8 9 10const result =// [ 51, 201, 251 ]
There are two variants; both return a Promise that resolves to a new array with the results.
const tr_async map filter =const wait =numbers = 1 2 4 5 6 7 8 9 10// [ 51, 201, 251 ]
tr_par instead of
tr_async. Parallel can be nice for speed, but
error handling can be tricky: Similar to using
.catch handler is called
at most once — if errors happen after
the first one, they are ignored!
- Functions passed to
filtermay return a value or a Promise... But:
- if Promises are involved, use
tr_paralways return a Promise
tr_arraydies in flames if a Promise is encountered. (
these are proper "transduce" type functions, see
 Egghead transducer tutorial (https://egghead.io/courses/quickly-transform-data-with-transducers)