Handling async API calls in Redux

WHAT THIS TESTS Whether you understand that reducers must be pure and synchronous, and that all side effects, including network calls, belong outside them in middleware. It probes your grasp of Redux's data flow and your ability to choose the right tool for a given complexity level.

A GOOD ANSWER COVERS Reducers cannot perform I/O, so middleware intercepts actions between dispatch and the reducer. Redux Thunk lets an action creator return a function instead of a plain object; that function receives dispatch and getState, so you can dispatch a pending action, await the request, then dispatch success or failure. Redux Saga runs separately as generator functions that yield declarative effects such as call, put, take, and takeLatest, enabling cancellation, debouncing, retries, and complex coordination. Thunk is lighter and fits most apps; Saga shines when you need orchestration, race handling, or highly testable effect logic.

COMMON WRONG ANSWERS Claiming reducers can make async calls, conflating middleware with reducers, or asserting Saga is universally superior. Forgetting that modern Redux Toolkit recommends createAsyncThunk, which standardizes pending, fulfilled, and rejected states, is also a gap.

LIKELY FOLLOW-UPS How does createAsyncThunk simplify Thunk patterns? How would Saga cancel an in-flight request when a new one starts? How do you test a Saga versus a Thunk?

ONE CONCRETE EXAMPLE For a user-profile fetch, a Thunk dispatches profileLoading, calls api.getUser(id), then dispatches profileLoaded with the payload or profileError on failure. The equivalent Saga uses takeLatest('PROFILE_REQUESTED', fetchProfile) so that if the user rapidly switches profiles, only the most recent request resolves, automatically cancelling stale ones, something Thunk cannot do without manual flags.