Are there any considerable benefits of using this over standard redux-saga?

[ctrlplusb]

Sorry, not trying to be snarky or anything. It's a genuine question of interest.

What do you feel are the benefits of using this implementation?

[slorber]

@ctrlplusb IMO if you are familiar this RxJs streams this approach is perfectly fine and elegant. I don't see anything in my app using redux-saga that could not be also solved by the rxjs counterpart

The only thing is that I don't think @tomkis1 has solved the testability/devtools issue yet and many people like redux-saga because of that.

But many also don't like so much generators so I guess try both on a small usecase and decide :)

[tomkis]

Thanks @slorber for the answer! I would probably write the same.

The thing is that there's no difference between redux-saga-rxjs and redux-saga because redux-saga is using async generators. Async generators are same like Observables.

From my perspective one of the benefits is its simplicity, redux-saga-rxjs is just few lines of code and everything else you need is provided by RxJS.

Some tasks are easier with streams like for example debouncing, throttling, delaying, cancelling etc. on the other hands Stream is completely different way of thinking so it might be a quite difficult for some people to grasp it.

However, the main benefit for me is composability in very functional way. I am building the Elm architecture in Redux and found rxjs-sagas much more easier to compose.

It's true that we don't have devtools at the moment, yet I believe that visualizing streams (http://jaredforsyth.com/rxvision/) is the best possible dev tools experience.

tl;dr: Unless you are experienced with RxJS, you probably want to stay with redux-saga otherwise you might find this approach a bit more natural and powerful.

[ctrlplusb]

Thanks for taking the time to answer this gentlemen. Much appreciated!