Closed nickbalestra closed 7 years ago
This is great! Certainly removes lots of repeated code from the main function. I'd be happy to merge this PR.
Just one small nitpick. Since it uses xs.merge
it will not work if you're using a non-xstream driver (say a RxJS driver). Thoughts?
@lmatteis this library itself only uses xstream and doesn't use Cycle's runStreamAdapter
, so it's not non-xstream friendly anyway.
In which case, this can probably be merged right off, and we could create a feature request on Issues for being stream library agnostic and see if enough people want/need that.
Also, while this is not definite yet, Cycle might eventually become xstream-only: https://github.com/cyclejs/cyclejs/issues/425
True, there's also xs.fromObservable
which could be used in case one of your "cycles" uses a non-xstream observable. For instance:
return {
ACTION: xs.fromObservable(rxjsObservable$)
}
Reading a bit more about it seems that the drivers must do the work of supporting several stream libraries. So since we use xstream-run
, we'll only support drivers that are xstream-compatible. I don't think you can just use a pure RxJS driver and expect it to work with xstream-run
right?
Cool, that's what I thought @goshakkk - I'll do a PR, together with example and docs.
Hi Luca,
as I've starting playing with your awesome project, I found myself using something similar to combineEpics&co. Here is how it looks like.
In the example you provided could be used like:
Let me know what you think, happy to open a PR if you feel like it will make sense to have it within
redux-cycle-middleware