Redux-Observable Epics vs Redux-Sagas

And Why Do I Care?

Firstly, to care about this battle you have to first understand JavaScript and Redux. If not, then you’re probably in the wrong blog article (should have taken a left at the gas station). Those who remain, let’s address the quandary at hand.

In Redux, there’s no prescribed way to handle side-effects. Such a blessing and a curse. Since the jury is out, there have been quite a few popular choices. Major companies like Slack and Netflix have chosen RxJS with Redux-Observable, while the popularity among React Native devs has soared with Redux Sagas.

I’m not going to sugar-coat this article… or even make sense since I’m turning the whole thing into a “fight”. If you’re happy with Thunks, and you’re not looking for a big dose of opinion, turn away now. This article will go where Github stars and brand names cannot. We should evaluate these two popular paths for what fits our own needs. Ladies and gentlemen

… it’s fight night.

In the Red Corner

Redux-Observable

Redux Observable Epics come from a deep history called Reactive programming. In JavaScript we use Reactive programming via RxJS. If you’re completely unfamiliar with RxJS and their observable stream pattern, it’s like a promise on steroids. A promise normally only has a single result, but RxJS observables return a “stream” of results over time.

Break it down:

RxJS — Reactive programming ported to JavaScript. Reactive programming has different names depending on the language the concepts are ported to. This is a great way to take your skills across several platforms.

Screenshot of Reactive lib languages and names

Confused on what observables are? You can play catch-up with Jeremy Fairbank’s awesome video:

Redux-Observable — Applying RxJS observable flow to Redux, and therefore handling async actions in middleware. Actions in -> Actions out styled workflow.

Epics — Observed actions whereby you can use a wide Reactive API from RxJS on Redux via Redux-Observable.

In the Blue Corner

Redux-Saga

Sagas conceptually come from Princeton as a way to handle processes. Using the Saga Process for flow-control and side-effects like async/cache etc. You plug them in as middleware and use them as a sort of “process” that fires at a given time. Sagas take advantage of generator functions to yield their control to your given workflow for redux-inspired events.

Break it down:

ES6 Generators — “Runnable in chunks” JavaScript code. This gives sagas the power to run and stop where needed.

Sagas — Apply a process manager for async, timed, or other non-pure effects so that you can keep application flow logic clean.