Redux Side Effects: Thunk vs Saga vs Observable

When building apps with Redux, you eventually need to handle things like API calls, timeouts, or logging. These are called "side effects" because they change things outside the store. redux-thunk, redux-saga, and redux-observable are the three main tools for this job. They all let you run async code, but they differ in syntax, power, and complexity.

🚀 Basic Async Logic: Fetching Data

The most common task is fetching data from an API and saving it to the store. Here is how each library handles a simple fetch request.

redux-thunk lets you return a function from your action creator. This function gets dispatch and getState as arguments.

// thunk: Basic fetch
export const fetchUser = (id) => {
  return async (dispatch) => {
    dispatch({ type: 'USER_REQUEST' });
    try {
      const response = await api.getUser(id);
      dispatch({ type: 'USER_SUCCESS', payload: response });
    } catch (error) {
      dispatch({ type: 'USER_FAILURE', error });
    }
  };
};

redux-saga uses Generator functions. You yield effects like call (for async) and put (for dispatching).

// saga: Basic fetch
import { call, put, takeLatest } from 'redux-saga/effects';

function* fetchUser(action) {
  try {
    const response = yield call(api.getUser, action.payload.id);
    yield put({ type: 'USER_SUCCESS', payload: response });
  } catch (error) {
    yield put({ type: 'USER_FAILURE', error });
  }
}

export function* watchFetchUser() {
  yield takeLatest('USER_REQUEST', fetchUser);
}

redux-observable uses RxJS Observables. You listen to the action$ stream and return a new stream of actions.

// observable: Basic fetch
import { ofType } from 'redux-observable';
import { mergeMap, map, catchError } from 'rxjs/operators';
import { of } from 'rxjs';

const fetchUserEpic = (action$) =>
  action$.pipe(
    ofType('USER_REQUEST'),
    mergeMap((action) =>
      api.getUser(action.payload.id).pipe(
        map((response) => ({ type: 'USER_SUCCESS', payload: response })),
        catchError((error) => of({ type: 'USER_FAILURE', error }))
      )
    )
  );

🛑 Handling Cancellation: Stopping Old Requests

When a user clicks a button multiple times or navigates away, you often need to cancel pending requests to avoid memory leaks or race conditions.

redux-thunk does not have built-in cancellation. You must use the native AbortController or track request IDs manually in the state.

// thunk: Manual cancellation
let controller;

export const fetchUser = (id) => {
  return async (dispatch, getState) => {
    if (controller) controller.abort(); // Cancel previous
    controller = new AbortController();
    
    try {
      const response = await api.getUser(id, { signal: controller.signal });
      dispatch({ type: 'USER_SUCCESS', payload: response });
    } catch (error) {
      if (error.name !== 'AbortError') {
        dispatch({ type: 'USER_FAILURE', error });
      }
    }
  };
};

redux-saga has built-in cancellation. Using takeLatest automatically cancels the previous task if a new action comes in.

// saga: Auto cancellation
export function* watchFetchUser() {
  // takeLatest cancels the previous fetchUser task automatically
  yield takeLatest('USER_REQUEST', fetchUser);
}

redux-observable handles this with RxJS operators like switchMap. It unsubscribes from the inner observable when a new value arrives.

// observable: Auto cancellation
const fetchUserEpic = (action$) =>
  action$.pipe(
    ofType('USER_REQUEST'),
    // switchMap cancels the previous inner observable (the API call)
    switchMap((action) =>
      api.getUser(action.payload.id).pipe(
        map((response) => ({ type: 'USER_SUCCESS', payload: response }))
      )
    )
  );

🧪 Testing Approach: How Hard Is It?

Testing async logic is critical. The ease of testing depends on how much you need to mock.

redux-thunk is straightforward but requires mocking dispatch and getState. Since it uses standard async/await, it feels like testing normal functions.

// thunk: Test example
it('dispatches success on fetch', async () => {
  const dispatch = jest.fn();
  const getState = () => ({});
  api.getUser = jest.fn(() => Promise.resolve({ id: 1 }));

  await fetchUser(1)(dispatch, getState);

  expect(dispatch).toHaveBeenCalledWith({ type: 'USER_SUCCESS', payload: { id: 1 } });
});

redux-saga is very easy to test because Generators return plain objects (effects). You do not need to run the async code, just step through the generator.

// saga: Test example
it('yields call and put', () => {
  const generator = fetchUser({ payload: { id: 1 } });
  
  expect(generator.next().value).toEqual(call(api.getUser, 1));
  
  const response = { id: 1 };
  expect(generator.next(response).value).toEqual(
    put({ type: 'USER_SUCCESS', payload: response })
  );
});

redux-observable requires testing RxJS streams. You need to use tools like rxjs-marbles or manually subscribe to verify the output stream.

// observable: Test example
it('maps response to success action', (done) => {
  const action$ = of({ type: 'USER_REQUEST', payload: { id: 1 } });
  api.getUser = () => of({ id: 1 });

  fetchUserEpic(action$).subscribe((action) => {
    expect(action).toEqual({ type: 'USER_SUCCESS', payload: { id: 1 } });
    done();
  });
});

📈 Complexity and Learning Curve

The choice often comes down to what your team already knows.

• redux-thunk is the easiest. If you know JavaScript functions and promises, you know Thunk. There is no new syntax to learn.
• redux-saga requires learning Generators (function*, yield). This syntax is less common in modern React code, which can confuse new hires.
• redux-observable requires learning RxJS. This is a large library with many operators (mergeMap, switchMap, concatMap). It is powerful but has a steep learning curve.

📌 Summary Table

💡 Final Recommendation

redux-thunk is the default choice for 90% of projects. It is simple, official, and gets the job done without extra complexity. Start here unless you have a specific reason not to.

redux-saga is best for complex apps that need advanced control over async flows, like background sync or heavy cancellation needs. It is also great if you value testability above all else.

redux-observable is a niche tool for teams already using RxJS. It shines in real-time apps with complex event timing, but it is overkill for standard CRUD apps.

Final Thought: All three libraries are stable and maintained. The best one is the one your team can understand and maintain six months from now.