Shubham Ankit

Shubham Ankit


Asynchronous with Redux Sagas

Originally published by  Jolene Langlinais at

Building an app with React can get a bit confusing when data is being shared among components and different states lead to too much complexity and difficulty. Redux is a lightweight state management tool which can be used with any JavaScript framework or library to maintain a consistent and predictable state container. By keeping the state of an application in a single global store rather than at the component level, each individual component can access any state it needs at any time regardless of the shape of the component tree, as long as it is connected to the store via Redux.

The predictable nature of Redux comes from the immutable state which never changes, as well as pure function reducers. Because reducers are functional, a commonly used middleware to handle side effect logic and asynchronous calls is redux-thunk. A Thunk allows action creators to return a function instead of an action.

While I will be assuming you have a basic understanding of React and Redux, this will be a guide into a different kind of Redux middleware for handling side effects: Redux Sagas

Why Redux Saga?

So long as the same action is passed to the reducer, we can be sure the store will be updated in the same way every time. Sagas, similar to normal reducers, are functions which listen for dispatched actions, perform side effects, and return their own actions back to the normal reducer. Because Sagas intercept actions with side effects and handle them, Redux reducers remain pure.

Redux Saga utilizes ES6 generator functions for this. Generators allow for synchronously written asynchronous code. A generator will automatically pause — or yield — at each asynchronous call until it completes before continuing. This paradigm allows for much simpler and more readable code by centralizing asynchronous logic for more manageable and sophisticated async flows.

Saga generator functions remind me a bit of async/await, with some minor changes such as yield and put(). Some of the differences provide powerful benefits, such as takeLatest() ensuring that only the latest fetch call runs to completion despite having dispatched multiple simultaneous fetch actions. However, asynchronous calls which would normally be directly inside an action creator in a thunk will have a clear separation in Redux Sagas.

Beyond code organization and attributes, testing becomes much easier. A Saga merely yields a description of what to call, thus saving the need for mocking data for every test.

Redux Saga becomes most useful when API or other asynchronous calls are being made with complex flows in which calls depend on the next.


+ More readable code

+ Good for handling complex scenarios

+ Test cases become simple without necessity to mock the async behavior


- Brings in more complexity to the code

- Additional dependency

- A lot of concepts to learn


→ Suited for complex async parts of the application that requires complex unit test cases

A quick note on Thunks:

Given that Redux Saga seeks to orchestrate complex asynchronous operations with Redux, it is an alternative to Thunks. However, Sagas provide more functionality. Thunks work well for simple use cases, but may not be the best choice for more complicated scenarios.

Thunks add a layer of indirection for more flexibility, and pass dispatch functions to the function the action creator returns. This allows the component to be agnostic towards asking for a synchronous or asynchronous action.


+ Simple code to maintain


- Struggles at handling complex scenarios

- Async behavior needs mocking for test cases


→ Suited for small, straight forward async parts of the application


Denoted with an *, generators make use of the yield keyword to pause the function. While async/await can be transpiled into generators, the reverse cannot be done. Moreover, Sagas’ takeLatest() behavior and generator function cancellation are more attributes provided by Redux Saga.

When a generator function is invoked, it returns an iterator object. Each subsequent next() method call will execute the generator until the next yield statement and pause.

function* testGenerator() {
  const first = yield 'first yield value';
  const second = yield 'second yield value';
  return 'third returned value';

const test = testGenerator();

console.log(; // { value: ‘first yield value’, done: false }
console.log(; // { value: ‘second yield value’, done: false }
console.log(; // { value: ‘third returned value’, done: true }
console.log(; // { value: undefined, done: true }


To guide through this concept, I will be referencing a codebase for the web app used by an open source software project I contribute to here:

Accord Project (AP)

AP Github

Template Studio repository

The project currently being built is a redesign of the Template Studio. Details are mostly unimportant, suffice it to say that the part I will be going through makes an API call to gather an array of templates, and displays them in a component. This redesign will consist of many interlocking React components, all housed in one app and controlled by the Redux store. Because this began complex and will only continue to be more-so, we chose to pursue Redux Saga to handle the complexity.

Unfortunately, as you may have experienced as well, there seems to be little out there as reference material. This is especially so when it comes to anything complicated.

This will be a guide to following the logic behind Redux Saga in Template Studio for Accord Project. Hopefully this will prove to be a useful resource for you.


Common Redux Saga methods (called Effects):

fork → Performs a non-blocking operation on the function passed.

take → Pauses until action received.

race → Runs effects simultaneously, then cancels them all once one finishes.

call → Runs function. If it returns a promise, pauses the Saga until resolved.

put → Dispatches an action.

select → Runs a selector function to get data from the state.

takeLatest → Executes the operation, returns only the results of the last call.

takeEvery → Will return results for all the calls triggered.

The overall structure of the application’s flow of data will look akin to this:

To begin, we set up the main render of the app, and applying a store to the Provider given by react-redux :

import React from ‘react’;
import { render } from ‘react-dom’;
import { Provider } from ‘react-redux’;

import MainApp from ‘./containers/App’;
import store from ‘./store’;

<Provider store={store}>
<MainApp />


Pulling in the createSagaMiddleware method from Redux Saga, we create sagaMiddleware and run it on our rootSaga, which we will see below. Moreover, we combine all of our reducers and include this in the store upon creation.

Similar to the reducers, Sagas will be registered with a rootSaga. Having the middleware use the rootSaga allows actions being dispatched to be successful.

import { combineReducers, createStore, applyMiddleware } from ‘redux’;
import createSagaMiddleware from ‘redux-saga’;
import logger from ‘redux-logger’;

import templatesReducer from ‘./reducers/templatesReducer’;

import contractReducer from ‘./reducers/contractReducer’;
import rootSaga from ‘./sagas/rootSaga’;

const sagaMiddleware = createSagaMiddleware();
const middlewares = [sagaMiddleware];

if (process.env.NODE_ENV === ‘development’) {

const rootReducer = combineReducers({
templatesState: templatesReducer,

contractState: contractReducer,

const store = createStore(

export default store;


Sagas work in the background and sagaMiddleware controls them. Being generator functions, Sagas have control over every single step of the function. We yield objects to sagaMiddleware which tell it what to do with given arguments, which it will execute and resume upon completion, thus appearing to operate synchronously.

Sagas are broken down to the root, watchers, and workers. All other Sagas you write are consolidated into root.

→ Root

All Sagas will be registered with a root Saga. Combined in an all()function, they are allowed to all start at the same time each time.

import { all } from ‘redux-saga/effects’;
import { templatesSaga } from ‘./templatesSaga’;
import { modelSaga } from ‘./modelSaga’;
import { logicSaga } from ‘./logicSaga’;
import { sampleSaga } from ‘./sampleSaga’;


  • saga to yield all others
    export default function
    rootSaga() {
    yield all([…templatesSaga, …modelSaga, …logicSaga, …sampleSaga]);
→ Watcher

Allowing the Saga to know when to start, this generator function watches for actions (similar to reducers) and calls worker Sagas to do an API call. This function is on Line 62 below:

import { TemplateLibrary, Template } from ‘@accordproject/cicero-core’;
import { version as ciceroVersion } from ‘@accordproject/cicero-core/package.json’;
import { takeLatest, put, select, takeEvery } from ‘redux-saga/effects’;

import * as actions from ‘…/actions/templatesActions’;
import * as selectors from ‘…/selectors/templatesSelectors’;


  • worker saga
  • saga to populate store with templates
    export function
    pushTemplatesToStore() {
    try {
    const templateLibrary = new TemplateLibrary();
    const templateIndex = yield templateLibrary.getTemplateIndex({
    latestVersion: false,
    const templateIndexArray = Object.values(templateIndex);
    yield put(actions.getTemplatesSuccess(templateIndexArray));
    } catch (err) {
    yield put(actions.getTemplatesError(err));


  • worker saga
  • saga which puts a mock template onto the array
  • of templates in the store
    export function
    addNewTemplateToStore() {
    const newTemplate = {
    uri: ${},
    name: ‘Temporary New Template’,
    version: ‘1.0.0’,
    ‘This is mock data to showcase an action to add a new template.’,
    yield put(actions.addNewTemplateSuccess(newTemplate));


  • worker saga
  • saga which checks if template is in the store
  • and loads the template if it is not
    export function
    addTemplateObjectToStore(action) {
    const templateObjects = yield select(selectors.templateObjects);

if (!templateObjects || !templateObjects[action.uri]) {
try {
const templateObj = yield Template.fromUrl(action.uri);
yield put(actions.loadTemplateObjectSuccess(action.uri, templateObj));
} catch (err) {
yield put(actions.loadTemplateObjectError(err));


  • watcher saga
    export const templatesSaga = [
    takeLatest(‘GET_AP_TEMPLATES’, pushTemplatesToStore),
    takeLatest(‘ADD_NEW_TEMPLATE’, addNewTemplateToStore),
    takeEvery(‘LOAD_TEMPLATE_OBJECT’, addTemplateObjectToStore),

Similar to takeLatest()takeEvery() allows multiple instances of Sagas to run simultaneously. These are both built on take(), which is synchronous.

→ Worker

This Saga (Lines 1431, and 46 above) will perform a side effect. Once data loads, the put() method is used to dispatch another action. This does not directly dispatch, but rather creates an effect description that tells Redux Saga to dispatch it. Because put() expects an action for an argument, it serves as an action creator. We modularized these actions out, though, as you will see below.


Similar to actions, reducers are the same for Redux Saga. This is simply a function that takes state and action as arguments, and returns the next state of the app. While an action only describes what happened, a reducer describes how the application’s state changes.

const initialState = {
templatesAP: [],
templateObjs: {},
error: null,


const reducer = (state = initialState, action) => {
switch (action.type) {
return { …state, templatesAP: action.templates };
return { …state, templatesAP: […state.templatesAP, action.template] };
return { …state, error: action.error };
return {
templateObjs: {
[action.uri]: action.templateObj,
return { …state, error: action.error };
return state;

export default reducer;


Moving into the component, we have a straightforward approach to setting up state and dispatching to result in cleaner code.

import React from ‘react’;
import PropTypes from ‘prop-types’;
import styled from ‘styled-components’;
import { connect } from ‘react-redux’;
import { TemplateLibrary } from ‘@accordproject/cicero-ui’;

import {
} from ‘…/…/actions/templatesActions’;

const TLWrapper = styled.div ...;;
const mockAddToCont = input => {
console.log('addToCont: ', input);
const mockImport = () => {
const mockUpload = () => {

export class LibraryComponent extends React.PureComponent {
componentDidMount() {

render() {
return (

LibraryComponent.propTypes = {
templates: PropTypes.array.isRequired,
addNewTemplate: PropTypes.func.isRequired,
fetchAPTemplates: PropTypes.func.isRequired,

const mapStateToProps = state => ({
templates: state.templatesState.templatesAP,

const mapDispatchToProps = dispatch => ({
fetchAPTemplates: () => dispatch(getTemplatesAction()),
addNewTemplate: () => dispatch(addNewTemplateAction()),

export default connect(

Action Creator

Dispatched to the store for handling, actions are objects containing a description of an event. Because actions are made by action creator functions, the one dispatching the action does not need to know the exact structure.

With Sagas, actions are slightly different. Three actions happen for each API call. Beginning the action, successful response, and error response. While this pattern does not change, the location of each call may.

Beginning an action starts within the component, which may add necessary info for making the call. Worker Sagas will be dispatching success and error actions.

export const getTemplatesAction = () => ({

export const getTemplatesSuccess = templateIndexArray => ({
templates: templateIndexArray,

export const getTemplatesError = error => ({

export const addNewTemplateAction = () => ({

export const addNewTemplateSuccess = template => ({

export const loadTemplateObjectAction = uri => ({

export const loadTemplateObjectSuccess = (uri, templateObj) => ({

export const loadTemplateObjectError = error => ({


  1. (TemplateLibrary.js) When the LibraryComponent mounts, an action (getTemplatesAction) is dispatched
  2. (templatesActions.js) As we can see, getTemplatesAction dispatches an object with a type: ‘GET_AP_TEMPLATES’.
  3. (templatesSaga.js) The watcher will pick up on the action of type ‘GET_AP_TEMPLATES’ and call pushTemplatesToStore.
  4. (templatesSaga.js) When pushTemplatesToStore is called, a few things happen. We yield an API call made by the TemplateLibraryimported from @accordproject/cicero-core and put it in an array. From there, getTemplatesSuccess is called with the array of templates as an argument.
  5. (templatesReducer.js) This action (GET_AP_TEMPLATES_SUCEEDED) ends up in the reducer, updating the state with the templates array which was attached to the action.
  6. (TemplateLibrary.js) Because this component is subscribed to the store and has props propagated to it, the templates array is now applied to this component through props.


Approaching testing for Redux Saga may be intimidating. A general rule for efficiency in Redux Sagas is to ensure Sagas are doing as little as possible and to move any complex logic out into a separate regular function. A couple approaches I would recommend pursuing:

Unit Tests

This approach steps through yield effects individually with the next()method. A test may inspect the yielded effect and compare it to an expected effect with next().value. While this is straightforward, it leads to brittle tests. This is due to the tests being coupled so tightly with the implementation and order of effects. Refactoring code will likely break tests.

A helper function called recordSaga is used to start a given saga outside the middleware with an action. The options object (dispatch and getState)is used to define behavior of side effects. dispatch fulfills put effects, and dispatched accumulates all the actions in a list and returns it after the Saga finishes.

import { runSaga } from ‘redux-saga’;


  • saga to test independently
    export async function recordSaga(saga, initialAction, state) {
    const dispatched = [];
    await runSaga(
    dispatch: action => dispatched.push(action),
    getState: () => state,

return dispatched;

Utilizing recordSaga allows us to view the type of the dispatched action in a given test case.

import { TemplateLibrary } from ‘@accordproject/cicero-core’;
import { addNewTemplateToStore, pushTemplatesToStore } from ‘…/templatesSaga’;
import { recordSaga } from ‘…/…/utilities/test/sagaTest’;

const mockedTemplateIndex = [
ciceroVersion: ‘^0.12.0’,
‘This clause allows the receiver of goods to inspect them for a given time period after delivery.’,
name: ‘acceptance-of-delivery’,
type: 1,
version: ‘0.11.0’,

jest.mock(‘@accordproject/cicero-core’, () => ({
TemplateLibrary: jest.fn(),

beforeEach(() => {

describe(‘pushTemplatesToStore’, () => {
it(‘should dispatch the action getTemplatesSuccess’, async () => {
TemplateLibrary.mockImplementation(() => ({
getTemplateIndex: () => Promise.resolve(mockedTemplateIndex),
const dispatched = await recordSaga(pushTemplatesToStore);

it(‘should dispatch an error if templates fetch fails’, async () => {
TemplateLibrary.mockImplementation(() => ({
getTemplateIndex: () =>
Promise.reject(new Error(‘Unable to recieve templates’)),
const dispatched = await recordSaga(pushTemplatesToStore);

describe(‘addNewTemplateToStore’, () => {
it(‘should dispatch the action addNewTemplateSuccess’, async () => {
const dispatched = await recordSaga(addNewTemplateToStore);

Integration Tests

This approach tests the effects you’re interested in. In this, you will execute the Saga until the end, mocking effects along the way. Because this is not run in isolation, results are more secure. Now refactoring should not break the tests nearly as easily. To make this process easier, we utilize the module by Jeremy Fairbank - redux-saga-test-plan , which helps to make assertions in the effects generated by Sagas.

This module contains expectSaga which returns an API for asserting that a Saga yields certain effects. It takes the generator function as an argument, along with additional arguments to pass to the generator. While expectSagaruns on runSaga, which we used in sagaTest, it provides a bit easier usage. This also means that expectSaga is asynchronous.

After calling expectSaga with assertions, start the Saga with run(). This returns a Promise which can then be used with a testing framework. We use Jest. If all assertions pass, the Promise will resolve.

import { select } from ‘redux-saga/effects’;
import { expectSaga } from ‘redux-saga-test-plan’;
import { ModelManager } from ‘composer-concerto’;
import { updateModelManagerSuccess } from ‘…/…/actions/modelActions’;
import { updateModelFileOnStore, validateModelFiles } from ‘…/modelSaga’;

describe(‘validateModelFiles’, () => {
it(‘should complete successful update to model manager’, async () => {
const modelFiles = {
‘test.cto’: `
* This is a comment

            namespace test

            asset Vehicle identified by vin {
              o String vin default="unknown"

            // this is another comment
            participant Person identified by ssn {
              o String name
              o String ssn
              o DateTime dob
              --&gt; Vehicle vehicle
const state = {
  modelState: {
const modelManager = new ModelManager();
Object.keys(modelFiles).forEach(fileName =&gt; {
  modelManager.addModelFile(modelFiles[fileName], fileName, true);

return expectSaga(validateModelFiles)



Redux Saga is amazing. They provide a very clean way of performing asynchronous calls in Redux, and encourages clear, modularized code. While it is possible to accomplish the same feat without it, this will prove quite difficult and I feel it is worth the time to learn.

Originally published by  Jolene Langlinais at


Thanks for reading :heart: If you liked this post, share it with all of your programming buddies! Follow me on Facebook | Twitter

Learn More

☞ Understanding TypeScript

☞ Typescript Masterclass & FREE E-Book

☞ React - The Complete Guide (incl Hooks, React Router, Redux)

☞ Modern React with Redux [2019 Update]

☞ The Complete React Developer Course (w/ Hooks and Redux)

☞ React JS Web Development - The Essentials Bootcamp

☞ React JS, Angular & Vue JS - Quickstart & Comparison

☞ The Complete React Js & Redux Course - Build Modern Web Apps

☞ React JS and Redux Bootcamp - Master React Web Development

#redux #javascript #web-development

What is GEEK

Buddha Community

Asynchronous with Redux Sagas
Sidney  Purdy

Sidney Purdy


Channels in Redux-saga

What are the channels? Are they useful to us in day to day programming? We’ll be going through this blog that channels are played really a major role in redux-saga.

Channels are of 3 types which are used to perform 3 different things, here I will brief you about those channels here but will explain in detail a bit later.

  • Action Channels: Action channel is a buffer, it stockpiles actions which sagas can consume one by one.
  • Generic Channels: Generally, we use Generic channels to communicate between two sagas. This can be done through the Actions but the idea of a channel is that communication is limited interest in sagas without other sagas being privy to that information.
  • Event Channels: Event Channel is completely different used to wrap outside event sources. we can consider web socket as a good example of the Event channel.

#react #redux #saga #redux-saga

Terry  Tremblay

Terry Tremblay


How to implement Redux Saga with ReactJS and Redux?

Intro to Redux setup tutorial

Very often, you can hear about the state in frontend applications, but what it exactly is? Let me explain.

State in frontend applications represents all the data stored in the application in a given time. It can be stored in different formats like objects or strings. Based on the state’s values, we can personalize the application, display, and hide certain elements.

To manage the state in modern frontend frameworks, we can use different libraries like Redux, MobX, or NgRx. The most common one is Redux, which is used mainly with ReactJS applications, although it’s possible to use it with Angular as well.

With Redux, the state of the application is kept in the store, and we can access the store from every component in the application. Redux consist of store, reducers, and actions.

In this article, I’d like to tell you more about the Redux library and create a simple ReactJS project, where I’ll set up a Redux step by step.

Let’s start!

How does Redux work?

Redux is based on the flux architecture, and it supports unidirectional data flow. It means that data in the application goes through the same lifecycle over and over again, which makes everything that happens in the state more predictable.

Let’s take a look at the simple graphic, which illustrates the data’s lifecycle in the Redux application.

Image for post

On the graphic above, you can see that from the UI, we trigger an action that passes the data to the reducer. Next, the reducer updates the store, which is the state of our application. The store defines the user interface.

Let’s think of the benefits which using Redux can bring to our development.

Benefits of using Redux

When you’re building the application, you know more or less how much data you will need to manage inside the application. In most cases, frontend applications have some functionality, and very rare they are just static websites. Commonly, we keep some user data, forms data, etc. inside the application state, and then it’s very useful to use a tool for managing the state.

The most popular solution in ReactJS applications is Redux. There are some important benefits to the popularity of this solution. Let’s take a look at them one by one.

  • predictable state — The state in Redux is predictable because reducer functions are pure; therefore, if we pass the same state and the same action, it needs to return the same result. Redux state is also immutable; it can’t be changed or modified.
  • easy to maintain — Considering that it’s predictable and very strict about the structure of the Redux application, anyone who knows Redux will understand it and work with it easily.
  • easy to debug — Redux allows us to log the behavior using available developer tools, makes debugging easier.
  • developer tools available — Redux has amazing developer tools, that can be used in the browser to see what’s happens in the backend.
  • server-side rendering — Redux supports server-side rendering by allowing to manage initial rendering. Redux sends the state of the application to the server with a response to the server’s request.

Above I listed a few benefits of using Redux to manage the state of your frontend application. Now, I’d like to go to the practical part, where we are going to set up a Redux with ReactJS application.

#javascript #react #redux-saga #frontend #redux

Effie  Predovic

Effie Predovic


Handle Multiple Sagas with Call & All Effect in Redux Saga

In this video, I am going to explain that how you can handle multiple sagas with the help of call and all effect in Redux Saga.

#redux #redux saga.

Felicita  Kunde

Felicita Kunde


React Boilerplates with Redux, Redux Saga and Best Practices

Learn about redux and redux saga.

Youtube channel: IPenywis -

#react #redux #redux saga

Redux Saga Example - React Notes Taking App. Redux Saga vs Thunks

Let’s rewrite the Redux Thunk based React application to Redux Saga.


#react #redux #javascript #saga #thunks