Closed jeengbe closed 1 month ago
Which operators do you think should be renamed? And which operators are missing that you'd like to see included?
Sorry, I somehow didn't think of including examples in the issue 🤦🏻♂️
Here are a couple of operators and functions I had to change during a refactor from rx to ix:
shared()
doesn't work the way it does in rxmergeMap
for concurrent mapping (where concatMap
is mergeMap
with concurrency=1 if I remember correctly.)I don't have a deep enough insight into observables/iterators to say whether some of the missing ones might simply not be necessary, or whether some must inherently work differently.
These are some of the places I found ixjs diverge from rxjs. Still, great job on the library, it works fantastically otherwise!
I'd be happy to open separate issues about pipe()
missing and share()
not working as it does in RxJS.
pipe
is a function on the Iterable/AsyncIterable prototype. I suppose we could look at splitting it out into a standalone function if we don't already have it?share()
is meant to share the same underlying source iterator between multiple consuming iterators (see tests), which is analogous to multicast with a Subject. You may want to look into memoize()
or publish()
for something closer to multicast with behavior/replay semantics.mergeMap
was implemented in https://github.com/ReactiveX/IxJS/commit/7b7d493e89d93c80ed619d1e1646aec4dc790cac, though it's called flatMap. It flattens inner sequences concurrently (similar to Rx), which deviates from the AsyncIterable Helpers flatMap definition. flatMap
over Iterables (and in prior versions of Ix, AsyncIterables) is indeed analogous to concatMap
.Thanks a lot! Your comment helped. I'll look into an MR for pipe
. 🙂
Mostly something to consider for the next breaking change. Might also be that changing Rx is more appropriate. Not actionable, so closing for now.
Hi!
IxJS is currently more difficult to use than it should be. On the one hand, the only real way to find the right operator is to inspect each source file and the respective documentation comment. Additionally, not all operators work the way they do in RxJS (or exist at all), which leads to confusion and mix-ups when having worked with RxJS before.
By sticking to RxJS naming convention, not only is migrating code from Rx to Ix easier, but the existing (good) rxjs.dev operator decision tree applies to Ix too.