Comments (8)
I am almost down for this. However:
- There are multiple libraries that do array-like iterator/async iterator functions.
- https://github.com/tc39/proposal-iterator-helpers
- https://github.com/jamiemccrindle/axax
- https://github.com/fitzgen/wu.js/
Could we use these libraries instead?
- As a general rule, I want to avoid exporting functions under the
@channel
namespace which do not use the channel class. Functions likefilterChannel
could be defined purely with an async generator:
async function *filterAsyncIter<T>(iter: AsyncIterable<T>, pred: (value: T) => any): AsyncIterable<T> {
for await (const value of iter) {
if (pred(value)) {
yield value;
}
}
}
Is there a reason we would use channels for these methods?
These should probably be functions and not instance level methods so the API doesn't differ from async iterators.
Yes, my thoughts exactly! 🥰
from repeater.
I believe these should return channels or utilize some API that allows chaining.
const numbersChannel = new Channel<number>(() => {});
const oddNumbersChannel = filterChannel(numbersChannel, item => item % 2 !== 0);
const oddNumbersGreatherThan50Channel = filterChannel(numbersChannel, item => item > 50);
const newChannel = something(numbersChannel) <-- not idea about the name
.use(filterChannel, item => item % 2)
.use(filterChannel, item => item > 50)
.toChannel();
or
const numbersChannel = new Channel<number>(() => {});
const newChannel = something(numbersChannel)
.filter(item => item % 2)
.map(item => `number:${item}`)
.toChannel();
Also, I think while at util functions we should add ones for converting async generators to channels and vice versa.
from repeater.
Also, I think while at util functions we should add ones for converting async generators to channels and vice versa.
If we adhere to the “no differences between async generators and channels” rule, we should never have to convert async generators to channels.
Even if you want to create a chainable API, I don’t think there’s a need to have a toChannel
call at the end. All you really have to do is make the something function return an async iterable somehow and then use this class interchangeably with channels. This could be a fun project idea!
from repeater.
Actually, now that I think about this “no differences between async generators and channels” rule it does not make much sense in a sense of extending possibilities of async generators.
The whole point of this package is to make work with "async iterable like" easier no? Channels are essentially an implementation of async iterators. As long as they extend the API of async iterators all the libraries utilizing async iterators should work just fine with channels.
There is zero need for converting channels to async iterators because channels are essentially async iterators. However async iterators are not channels so that's why we should create some asyncGeneratorToChannel
utility function.
from repeater.
Actually, now that I think about this “no differences between async generators and channels” rule it does not make much sense in a sense of extending possibilities of async generators.
Yeah this library isn’t about extending async generators, just making it easy to convert callback-based APIs to async iterator-based APIs. Once you have channels, they are completely indistinguishable from async generator objects.
As long as they extend the API of async iterators all the libraries utilizing async iterators should work just fine with channels.
Yes, exactly.
However async iterators are not channels so that's why we should create some asyncGeneratorToChannel utility function.
This is easy to write with the Channel API:
function convertIterToChan(iter) {
return new Channel(async (push, stop) => {
for await (const value of Channel.race([iter, stop])) {
await push(value);
}
stop();
return stop;
});
}
But again, my question is, if you already have an async iterator/able, what is the point of upgrading it to a channel? What additional value is derived if you assume that channels are indistinguishable from async generators? Insofar as channels are indistinguishable from async generator objects, you could write an equivalent convertIterToChan
with an async generator too!
async function *convertIterToGen(iter) {
for await (const value of iter) {
yield value;
}
}
Or even shorter:
async function *convertIterToGen(iter) {
yield *iter;
}
The only difference between convertIterToGen
and convertIterToChan
is that the constructor of the returned iterator is a native generator object in the first case, and this library’s channel class in the second.
from repeater.
Async generators do not have utilities for manipulating them ex.: filtering, mapping, combining/merging, etc. I believe filtering/mapping can be easily done but more complicated scenarios of merging are much easier with channels.
from repeater.
Async generators do not have utilities for manipulating them ex.: filtering, mapping, combining/merging, etc. I believe filtering/mapping can be easily done but more complicated scenarios of merging are much easier with channels.
Channels will never have utilities for filtering/mapping unless async generators gain these methods as well. Additionally, the channel combinator functions make a conscious decision to only take AsyncIterable
values as parameters; they never require their arguments to be channels. Typically, everything you need for filtering, mapping, etc. is already exposed via the AsyncIterable
interface. In your above example, I’m not sure why or how intermediate channels would be used to implement map/filter, and I guarantee those things can be done with async generators (and you can create a fluent chainable API with a little bit of extra work).
I think there is definitely a need for a library which does what you’re saying, and it would be even better if it were both typed with TypeScript and polymorphically sync/async according to whether the arguments passed to it are Iterable
or AsyncIterable
. I encourage you to experiment with this stuff and let me know what you discover!
from repeater.
Reopening this cuz I plan on moving the combinator static method to a separate module and adding combinators.
from repeater.
Related Issues (20)
- Create a logo HOT 1
- Redesign Repeater.prototype.return and the stop promise.
- Question: Convert Observable to Repeater and back HOT 5
- Missing documentation for packages HOT 2
- Not that great for implementing transducers? HOT 31
- Should the Repeater automatically stop when its executor fulfills? HOT 5
- Doesn't quite match AsyncIterable interface? HOT 3
- push*(repeater) type API HOT 3
- Some of the more fragile tests are failing in newer versions of node HOT 1
- Question about the abilities of async iteration HOT 2
- Repeater.race typings are incorrect HOT 1
- Aggressive memory leak in Repeater.race HOT 2
- 4.0 changes HOT 4
- TypeError: Invalid attempt to iterate non-iterable instance. HOT 5
- WeakMap error at Repeater.return HOT 8
- RepeatOrNot HOT 1
- Question about merging two Repeaters HOT 2
- Help with map transducer? HOT 13
- Stop promise not entirely compatible with Promise.race
- Event loop can die if stop() not called
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from repeater.