Introduction to Redux Saga
1 What is Redux Saga?
Redux saga is a redux middleware that allows you to manage your side effects (i.e. reaching out to the network) in an easier and more testable way.
This tutorial gives a conceptual introduction to redux saga and explains its purpose.
1.1 How does Redux saga work?
Redux saga is a middleware that you can plug into your
Redux store to soup it out a little bit.
The redux-saga docs state that ‘the mental model is that a saga is like a separate thread in your application that’s solely responsible for side effects‘. What does that mean? Well let’s make it visual, so it is easier to understand.
For illustration purposes let’s assume that we have a button in our application that loads some data when clicked. For simplicity, let’s assume we only have one action called
FETCH_DATA. Note that the following illustrations are not perfectly accurate. Technically speaking the
redux-saga-middleware is part of our top level /
App component. However, in here, for illustration purposes, the images sort of suggest that the
redux-saga middleware and the
App component are somewhat separated.
We do this because
redux-saga is easier to understand with a few illustrations.
Click on the image to see it in high resolution.
In our illustrations circles are supposed to represent actions, i.e.
type property. The
redux saga-middleware listens to all actions that are dispatched in our app. A
saga is listening for a specific action type. In the above illustration, the red circle represents the
1.2. Consuming actions
As soon as an action is dispatched that our saga is listening to (the red circle), our saga will consume it. You can think of this like taking away they action from an overall stream of actions.
1.3. Watcher Sagas and Worker sagas
Once our action is inside our saga, our saga will probably extract the payload from it. Typically we pass parameters we need for our API call in our actions. After extracting the
payload, the so called
watcher saga (on the left) typically creates /
forks a worker saga that will do the actual network request.
If you take a closer look at the illustrations, you see that we labelled the left saga as a watcher saga. When using
redux-saga, you typically end up with two sagas for one particular action. The first saga is quite primitive and is only listening whether an action with a specific type, e.g.
FETCH_DATA is dispatched and extracts the action’s payload if needed. If the watcher saga detects the action it is looking for, it creates a worker saga.
Now, there are two options. The
watcher saga can either wait for the result of the worker saga and then resume listening for new actions. It could also perform a fire and forget approach. That is, it is creating (
worker saga and immediately resumes listening for new actions. Both approaches make sense depending on what you want to do.
worker saga gets the result back (either
failure), it is dispatching an action with the server’s response (
F). This action then flows into the reducer where the next state is calculated. In our illustration, we assume that the request was successful.
2 Wrap Up
Now you’re probably wondering where the code is.
Well, the goal of this tutorial was to explain on a conceptual level how
redux-saga works, not to copy the redux-saga docs 😁.
I can only refer you to its excellent documentation. With the conceptual knowledge on how
redux-saga works, it should be very easy for you to understand their examples. I just feel that it is pointless to put a simple example here because there are already plenty of examples on their website.
My goal was to create some illustrations that make it clear what
redux-saga is doing.
I wrote it because I had problems to understand it on a conceptual level at first.Follow @productioncoder
Please follow me on Twitter @productioncoder to stay up-to-date. I’m happy to receive feedback of any kind.
If you are interested in more high-quality production-ready content, please enter your email below.