Should I always use redux-saga call effect for functions that return promise?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
In Redux Saga, you can either yield a Promise directly or yield a call effect that invokes a Promise-returning function. Both approaches can work, but they are not equally maintainable in team codebases. In practice, call should be your default for async side effects because it keeps saga logic declarative and test-friendly.
What call Actually Buys You
call wraps invocation details into an effect description. This makes generator behavior explicit and easier to assert in unit tests.
With this pattern, tests can verify yielded effects without executing real network calls.
Yielding Raw Promises
Saga can resolve raw Promises yielded from generator functions.
This works at runtime, but the side effect boundary is less explicit. It is harder to enforce consistent testing style when some sagas yield effects and others yield raw Promises.
Practical Rule for Team Consistency
A useful guideline:
- use
callfor async operations and impure functions - call pure synchronous helpers directly
- keep style consistent across the repo
Example with pure function called directly:
This keeps saga code concise without wrapping every tiny function in effects.
Cancellation and Abort Handling
Cancellation logic is clearer when async calls are isolated and explicit. Combine call, cancelled, and AbortController for fetch flows.
The intent is obvious: one effect starts I/O, another handles response parsing, and cancellation cleanup is deterministic.
Composability with Other Effects
call composes naturally with race, all, retry, and custom wrappers for telemetry.
Keeping async work in call effects makes these patterns straightforward and consistent.
When Direct Promise Yield Is Acceptable
For very small, isolated experiments, direct Promise yield is fine. The issue is not correctness; it is long-term readability in production code. If multiple developers touch sagas, consistency usually matters more than saving one line.
If you decide to allow both styles, document the rule clearly in contribution guidelines and lint conventions.
Common Pitfalls
- Mixing raw Promise yields and
calleffects arbitrarily across files. - Wrapping every synchronous helper in
call, which adds noise without benefit. - Assuming
callalone handles cancellation without explicit abort logic. - Testing full network behavior in saga unit tests instead of asserting yielded effects.
- Ignoring team conventions and creating multiple incompatible saga patterns.
Summary
- You do not always need
call, but it should be the default for Promise-returning side effects. - '
callimproves declarative style, composability, and unit testing clarity.' - Keep pure synchronous helpers as direct calls.
- Pair async
callusage with explicit cancellation and timeout strategy. - Prioritize one consistent saga style across the codebase.

