Member-only story
Refactoring From Redux Thunk to Redux-Saga
Improving the scalability of a JavaScript app
Many of you who are reading this probably have some experience with using Redux Thunk, know what it does, and are perhaps thinking of switching to Redux-Saga.
Just for a quick refresher, let’s consult Redux Thunk’s docs:
“With a plain basic Redux store, you can only do simple synchronous updates by dispatching an action. Middleware extends the store’s abilities and lets you write async logic that interacts with the store.
Redux Thunk middleware allows you to write action creators that return a function instead of an action. The thunk can be used to delay the dispatch of an action or to dispatch only if a certain condition is met.”
OK, so Redux Thunk works well. Then why would we want to choose Saga instead? As with any decisions, there are always pros and cons associated with each. I think the main reason you would choose Thunk over Saga is for quick and simple projects, as setting up Thunk is much easier. Besides that, Saga is almost always the way to go.
Why Redux-Saga?
“Redux-Saga is a library that aims to make application side effects (i.e. asynchronous things like data fetching and impure things like accessing the browser cache)…
