Remove dependency on RxJS (aka observable library agnostic)

Author: jayphelpsCreated Oct 10, 2016Updated Dec 9, 2025

While we love RxJS, there are indeed a large number of competing stream libraries. The paradigm this library intends to provide isn't in fact tied to RxJS and so other "ports" of redux-observable will eventually continue to pop up. e.g. redux-most.

IMO we should at least consider, "what if redux-observable didn't actually depend on RxJS at all?".

We use a couple RxJS operators internally right now, but mostly out of convenience. At first blush it seems we could get away without it. We would want to take great care that we're not reinventing too much of RxJS--it may turn out that reducing the number of RxJS operators we use internally is enough to no longer make it a peer dependency and instead, depend on it explicitly as merely an implementation detail, though even this isn't ideal because all of RxJS v5 is still in our node_modules and at least one prominent Electron user has reimplemented redux-observable for v4 for that reason alone.

I think the biggest question is actually how the ergonomics to RxJS might suffer in exchange. I do want to lean on the proposed ECMAScript TC39 Observables spec as the core, so regardless of the stream library you wanted to use, it would have to support the Observable spec, or there at least be a way for someone to convert between them. most.js, xstream, kefir already support it, with bacon.js support in discussion.

There would also be a question of documentation complexities. I'm not sure how maintainable it is to make separate versions of the docs for each stream library. In practice, it would likely end up being "RxJS v5 examples are documented by us, PRs for others are happily welcome" until we could make relations with other stream library users who would be willing to join some sort of "redux-observable core team"

So I think in that case, everyone would want to use an adapter, even RxJS users.

javascript
import rxjsAdapter, { combineEpics } from 'redux-observable-rxjs';

const rootEpic = combineEpics(epic1, epic2);
const epicMiddleware = createEpicMiddleware(rootEpic, { adapter: rxjsAdapter });

This does indeed increase setup friction a bit. Is it worth it to unify the communities long term? Nearly everyone reading this is probably an RxJS user, so I implore you to have empathy for others who don't share you opinion of Rx and objectively consider whether a little extra friction will make redux-observable better for everyone.


Don't freak out or get your hopes up. This is just to gauge community thoughts at this point. We may in fact be jumping the gun on this, and perhaps someone has arguments to let the communities grow independently?

If you have no comments other than agreeing/disagreeing feel free to add your "reaction" directly on this post with

Cc/ @joshburgess

Source: redux-observable/redux-observable