christyharagan / IxJS

The Interactive Extensions for JavaScript
MIT License
9 stars 2 forks source link

Road map? #3

Open OliverJAsh opened 7 years ago

OliverJAsh commented 7 years ago

Hey Christy!

I was looking for a library with a set of iterable transformers/helpers. I first came across Functify which now seems unmaintained, then IxJS, and then this rewrite of IxJS.

I was wondering whether there's any kind of road map for this project, in terms of release and which helpers are planned for addition.

Are plans to add any of these helpers? take, skipWhile, takeWhile, flatten, and flatMap. I ask because these are what I need for my project (where I'm currently using a modified version of Functify).

/cc @mattpodwysocki

christyharagan commented 7 years ago

Hey Oliver :)

Honestly, the roadmap so far has been "as I need them". I'm actively using this project for a number of other projects, and I'm adding the operators as I require them.

However, I would love other active users of this project, so would be very happy to add more operators that you need.

First, a point of note: I've called flatMap "concatMap"; I suppose I should add an alias flatMap (that might make sense as I know it's more commonly known as that).

For the others, I'll add (or feel free to add yourself) an issue for each operator. I'll add them as soon as I can (but again, I'd happily take pull requests :) ).

OliverJAsh commented 7 years ago

Thanks for the fast reply!

More than happy to contribute to this project. I've been looking for a project like this for awhile, glad to see some clever people are working on it 😄

Are there any plans to combine forces with the original repo/@mattpodwysocki at some point, as I noticed both repositories were active?

Here is my first attempt at a take operator for sync iterables: https://github.com/OliverJAsh/IxJS/commit/fa52b6383b45f899f47b646277adb4ab1517ebdf. If that looks OK, I will implement the same for async iterables. (On that note, I wonder how much code we can share for the sync/async implementations?)

Looking through the code I noticed an absence of generators. I was wondering if there are any particular reasons for this? I don't bring any preferences myself, but eager to learn from others!

Here is an implementation using generators: https://github.com/OliverJAsh/IxJS/commit/99293725a35cb00cfdd012d7bf4c5d738ac19ead

mattpodwysocki commented 7 years ago

@OliverJAsh IxJS isn't being neglected especially if you look at the graph as of late. I'm busy rewriting the Iterator and Iterable classes to support Symbol.iterator as well as AsyncIterable and AsyncIterator classes which is to support Symbol.asyncIterator.

@christyharagan I'd love for these efforts to merge quite honestly as I think this is going to be a new way going forward for us to think about backpressure, etc especially with Node and Browser streams.

mattpodwysocki commented 7 years ago

@christyharagan I'm keeping mine flatMap due to the hopefully forthcoming flatten and flatMap proposals from @bterlson

christyharagan commented 7 years ago

@OliverJAsh : Thanks for the implementation looks good. The only suggestion I'd make is to use $$iterator instead of Symbol.iterator. It's because $$iterator is a fallback for pre-ES6 systems: if Symbol.iterator exists, it'll be that value, otherwise it defaults to a string equivalent.

In terms of why I don't currently use generators: Again, it's for backwards compatibility. TypeScript does support generators but only when targeting ES6. They have ES5/ES3 transpilation support for generators coming (currently tagged at the next+1 release of 2.3). I know Babel supports this currently, but it's an extra tool in the build-chain, and I like my builds simple :D

I would, however, love to rebuild using generators as I think it makes implementation much nicer. Once TypeScript adds the necessary support, I'll certainly do so.

I'm happy to take a pull request for your changes (plus the $$iterator change) :)

@mattpodwysocki Yes, I am still keen to merge the efforts. I'm happy to contribute to your repo, as it has more visibility, and is clearly attached to RxJS. How would you like to go about merging the efforts? Pull request? I suspect my coding style may not be to everyone's preference (I tend to drop semi-colons, for example).

OliverJAsh commented 7 years ago

Thanks for the implementation looks good. The only suggestion I'd make is to use $$iterator instead of Symbol.iterator. It's because $$iterator is a fallback for pre-ES6 systems: if Symbol.iterator exists, it'll be that value, otherwise it defaults to a string equivalent.

I believe I did do this, only I had to use Symbol.iterator in type positions. I copied this from the filter command. Is this OK, or is there a way to use $$iterator in type position?

Regarding compatibility, that makes sense, thanks for letting me know 🙂

I'll raise a PR now!