But while middleware is easy enough to consume, a functional understanding of them is commonly overlooked when starting out with Redux. Inevitably this leads to more confusion, and limits the utility of Redux.

This article is divided into two main parts:

1. We will discuss what middleware is and how it gets hooked up to the store, and we’ll go through an example of how Redux Thunk is implemented and consumed.
2. (Optional) We will look more closely at how middleware is wired up and consumed internally by Redux.

So let’s dive in and see what middleware really is under the hood.

Part One: What is middleware?

Redux middleware is a function that sits between a dispatch and a reducer function. It does this by wrapping and enhancing the dispatch function.

Middleware is passed into to the store on creation using applyMiddleware(…middlewares). This will be discussed in more detail later on

Note: …middlewares refers to the use of the spread operator, which accepts any number of inputs and interprets them as an array of inputs.

Middleware are written to be composable, meaning that multiple middleware functions can be run one after the other, where the output of one middleware is forwarded to the next. At the end of this chain, an action must be produced to be sent to the reducer.

Middleware can do a few things:

• Transform a dispatched action into another action
• Forward an action to the next middleware
• Call dispatch with a new action
• Run some code, such as logging

Example: The simplest middleware

The simplest possible middleware is one that simply receives an action and forwards it to the next middleware. This is written as:

Before you run screaming, let’s talk about what’s happening here. The intimidating part here is called currying. This is a functional programming concept where a function returns another function. Here there is a function which returns a function, which returns a function. It’s a lot to look at in so little code, so let’s break it down.

Next(action)

We’re familiar with store and action, but what is next? As we’ve discussed, next is a function that forwards an action to the next middleware. Notice its function signature is the same as dispatch.

We can see this simply as a dispatch function that dispatches to our next middleware as opposed to going back to our top level store, which would bring it back through our middlewares.

In practice this means that applying a middleware is an enhancer on a dispatch call.

Example: Applying our simple middleware

To apply our middleware, Redux provides applyMiddleware(…middlewares). We will discuss what’s happening here under the hood in a bit. Consider the following application, using the middleware defined above:

Redux Thunk: decomposed

Let’s take a look at another simple, but widely used, piece of middleware, Redux Thunk.

Redux Thunk is simple: it allows us to dispatch a function as opposed to dispatching an action. This is useful as it gives us the ability to do two main things:

• Execute asynchronous code. Whereas the rest of the Redux workflow is entirely synchronous, functions executed inside middleware may be asynchronous
• Dispatch side-effect actions. Redux Thunk provides the functions passed to it a reference to dispatch(action) and getState()

Let’s take a look at a simplified implementation:

That’s it! All Redux Thunk middleware does is:

1. Check whether it is passed an action or a function
2. If it receives a function, that function is invoked
3. If it receives an action, it does nothing and forwards it to the next middleware

Example: Consuming Redux Thunk

Note: This example uses async/await

In this example, we are making a call to a fake Reddit API for posts. The following occurs:

1. getPosts(subreddit) creates a function that will make our API call
2. This function is passed to dispatch(action)
3. Because this is a function, it is invoked by Redux Thunk
4. The API call is executed
5. Success or failure actions are dispatched

This is the power of middleware. With relative ease, we are able to invoke an API call which is executed asynchronously, and which dispatches side-effect actions automatically depending on whether it succeeds or fails.

At this point, you know everything you need in order to get started building and consuming your own middleware! In the rest of this article, we’ll dive into some of the details of the Redux framework and see how Redux consumes our middlewares.

Part Two: How exactly does middleware enhance our dispatch?

This is equivalent to:

This is the underlying concept of how Redux uses middleware to wrap or enhance dispatch.

Example: Multiple middlewares

Now that we’ve got one middleware in place, it’s useful to look at a composition of middlewares. Consider the following middlewares:

Let’s try a naïve attempt at applying these middlewares to transform our dispatch:

Which can be expanded into the equivalent:

Ok, that’s still not exactly digestible. Let’s look at how it would work when called:

Can be expanded into the equivalent:

As it turns out, our middlewares are being called in the opposite order from which they are applied. This isn’t exactly what we want.

This of course is in line with the recursive structure of applying this middleware, which can be viewed as pushing each middleware onto a stack.

The solution is simple: reverse the order we are applying our middleware.

How does middleware application work?

Now that we have an idea of how we could manually apply our middleware, we can take a look at the applyMiddleware(…middlewares) function provided by Redux. Here is a simplified example of that function from the Redux docs:

As you can see, this is doing precisely what we did above manually. First, the middlewares are shallow-copied with slice(), and are reversed() to preserve desired ordering. Then dispatch is reassigned as the output of the middlewares.

This is functionally all we need to understand in order to write our own middleware, but there are a few distinct differences between our implementation of applyMiddleware(…middlewares) and the internal implementation, as discussed in the Redux docs:

• applyMiddleware(…middlewares) returns an enhancer function in order to ensure that middleware can only be applied once
• It exposes only getState() and dispatch(action) from the store
• store.dispatch(action) is not overridden, so we may still call it from within our middleware, which is very useful for actions which cause other side-effect actions (more on this later)

The implementation of the enhancer is not important for our purposes, but if you’re curious the signature is:

const enhancer(...middlewares) => (createStore) => createStore;

Creating your store with applied middleware

So there you have it! You can now apply and create your own middleware to accomplish all manner of things from making API calls to enhancing your application logging.

I feel your pain. A couple years ago I made the switch from C#/.NET to the world of React/Redux, and I was excited to get started. React was tough at first, but there was a wealth of resources for all skill levels. Then came Redux, and looking back it’s hard to imagine getting started.

So, in this article I’m going to break down Redux into the simplest terms I can. In fact, we won’t be using any React. Let’s get started!

What is Redux?

Redux is a place to store your application state. That’s pretty much it! At the end of the day, Redux is a wrapper for an object that represents your current application state. This wrapper encapsulates your state to ensure that it is only altered or read a certain way.

Terms

Action

A plain object with a type string and a payload. The payload can be whatever you like, but is typically and object.

Store

An encapsulation of your application state, which provides three main functions: getState(), dispatch(action), and subscribe(listener).

getState() is used to read the current state of the store.

dispatch(action) is used to change the state of the store using an action.

subscribe(listener) is used to listen for changes to the store. The listener is a callback with no arguments and no return value. subscribe(listener) returns an unsubscribe() function that can be used to remove the listener.

In order to determine how the state of the store will be changed by an action, the store is constructed with a reducer function.

Reducer

A function that specifies how an action that is dispatched to the store will modify the application state. This function takes an input state and action and returns a new state. This function must be completely synchronous.

Important

Notice that in the example above the reducer function does not modify its input state (or action), and instead returns a copy. This is crucial in Redux, and illustrates two functional programming concepts:

1. Immutability: the state is not modified, but instead is replaced by an entirely new object. This makes checking for updates much easier as only a reference check is required.
2. Pure function: the reducer function produces no side-effects (unintended changes to external state).

Another thing to note is that a reducer may receive a state of undefined. In order to handle this, we can use default value assignment:

In this case, when the reducer above is called with a state of undefined, the reducer will instead interpret the state as an empty object.

Example - Putting it all together

Ok, great! At this point you should have a good baseline for Redux, but as with most frameworks, sometimes conventions add confusion. Let’s talk about a few conventions that can make working in Redux more elegant.

Action Creators

These are functions that return an action. It really is that simple- a function that returns an object.

Combining Reducers

So far our examples have been with a shallow store, making our reducers simple and straight-forward. This does not work for bigger applications, where we might want to track our state by a composition of sub-states. Take this store shape, for example:

We could, of course, write the logic to handle updates to this state, but it would be easier to manage the properties of this state with their own individual reducers. Luckily, we can do exactly that. In the following example we will create a fredReducer and a georgeReducer, and we will write them completely in isolation of one another.

Now, all that’s left to do is combine them. Lucky for us there’s a function combineReducers provided in Redux. With it, we can provide an object with the keys we would like to use in our state, and whose values are our corresponding reducer functions. From combineReducers, we will get a function which we can provide to createStore(reducer, initialState) as our top level reducer.

Well, there you have it! Those are the basics of Redux. I hope this has been helpful in removing some of the confusion that clouds this framework, because I think it’s a truly great paradigm.