Epic Middleware in Redux

Kevin Salter
Nov 20, 2016 · 3 min read

RxJS and redux-observable

Middleware is a powerful feature of Redux applications that “provides a third-party extension point between dispatching an action, and the moment it reaches the reducer”. This means that you can access dispatched actions as well as the store, and then do things like impure, asynchronous tasks (such as talking to the server) and optionally dispatch new actions.

Redux-observable is middleware for Redux that uses RxJS under the hood to turn every action emitted by your Redux app into an observable stream. The core primitive of redux-observable is called an epic, which is a function that listens for actions on that stream, and allows you to react to those actions before optionally emitting new actions yourself — actions in , actions out. The middleware does this by calling .subscribe(store.dispatch) for you behind the scenes on every item emitted by your root epic. Here’s an example of what an epic might look like:

redux-observable literally takes the items emitted by your root epic and sends them to store.dispatch

at the highest level, epics are “actions in, actions out”

Epics are “long-lived” — they start up when your Redux app is initialized, and continue running until your app terminates. Even though redux-observable is middleware, it might be easier to think of epics as running in parallel to everything in the normal redux cycle. Here’s one way to visualize that flow:

image credit: http://makeitopen.com/tutorials/building-the-f8-app/data/ (I just added the middleware section)

In this flow, epics can’t swallow actions, or prevent or modify anything within the redux lifecycle. This means that dispatching an action from your UI will always reach the reducers. In fact, by the time an action reaches your epics, it’s already been run through your reducers. Epics are just listening for all actions, filtering the ones they care about, doing some side effect-y things, then optionally emitting any new actions you want to dispatch.

Ok, so, what’s a practical example of solving a real problem with epics?!

How about autosave.

Imagine you have an input field, and every time a user types something into that field you’d like to debounce their keystrokes, show some saving UI, make a call to the server, and then show some other UI to confirm that the save was successful, or that there was an error.

Image for post
Image for post
an example of autosave using redux-observable

Leaning on redux-observable middleware, we can achieve all of this functionality in barely 13 lines by using just a handful of Rx operators. If we include the imports, we’re looking at about 29 lines in total:

I think it’s pretty powerful (and really cool) to have one composed stream that handles all of these concerns so tersely, while fully handling success and error scenarios. 👌🏻

In the next post I’m going to talk about how we can go about writing unit tests for this!

Kevin Salter’s Blog

writing code and building products

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store