Service Error Handling With Redux-Saga
We have been talking about Service Error Handling with Redux-Saga which is a cool way yet not only for error handling but the application itself with side effects.
Redux-Saga is a library that makes it very easy to control the application and easily adapts to the application architecture.
If you don’t know what Redux-Saga yet! Keep reading… Redux-saga is a redux middleware and allows you to take actions by listening to redux actions. We can run, stop and cancel it by an action dispatch.
Yes by only dispatching an action will make you control your application outside of your components! And you will have the chance to manipulate/transform your data in SAGAS!! Very concise.
Regarding cancellation, I desire to share that it attracts our attention more besides starting and stopping actions that can be cancelled.
With the help of Redux-Saga and try{}catch{}block, We will read the status codes of the services “200, 300, 400, 500” instead of exceptions thrown by functions, and briefly talk about how our applications take advantage of this call management.
try {} catch {}
This is an approach that allows you to manage your services with only one Saga and take action accordingly, the rest is under your control! Perform anything you desire. Now! We will proceed with handling error responses returned from services.
The example may or may not meet your expectations, so bits of advice are welcome :)
Let’s Go:
For a user who logs into your application, you can listen to the login service and dispatch an action you want when this service resolves (async).
So what would you do when the service resolves?
- You can allow the user to login to your application and redirect her to another path.
- You can show users an informative modal/flag/notification about the ERROR returned from the service … “* Your password is Wrong. Etc *”
- You can manage the side effects “* accessing local storage, calling a different API. Etc. *”
Undoubtedly, it is difficult to establish such a comfortable reactive structure without using Redux-Saga. There are many ways to manage Service Error Handling without Redux-Saga. However, these methods quickly become complex and lose their scalability.
File structures and global objects, unfortunately, those approaches lose control as the application grows. There are also situations where you may have to disrupt a singleton structure.
Since the end of 2017 and starting in 2018, we have been generating all our applications with this architecture. Calling services and managing service status codes with a single Redux-Saga generator is now enrolling from the first row at each projects planning stage.
Generally, we use Axios to call services. The reason we chose Axios over browsers Fetch API is that it parses the response and can cancel the service on the fly. As far as I know, these two features can now be made with the Feth API.
When we evaluate the above conditions, I think that handling service status codes with Redux-Saga have a very important value both in terms of architecture and continuity of the project. You will manage your services without leaving React and you will be using a decoupled architecture.
The most important reason for using Redux-Saga is that it can be easily added, modified, scaled (managed) and even extracted in an already growing project!
One Saga For All Services
Even though the statement of a “single Saga that will rule all services ” seems a bit pretentious and cool at first glance, but it should be given its due. It works very well.
We will be able to manage the error codes. By calling methods such as GET, POST, DELETE, UPDATE from the library (Axios) you used to call services in Redux-Saga
The call() method we use in callWrapperSaga() should return a yield using the fn and …argsparameters that we have given to callWrapperSaga() so In the generator where callWrapperSaga() is called, we will be able to read the data returned from the services.
Service Error Handling with Redux-Saga
We called it a JavaScript Generator that rules all services. It takes the service instance and the values we want to send in the body of this service function as parameters
Below, you can find GET and POST generators demonstrating service calls.
So let's handle errors inside callWrapperSaga() it is the easiest thing :)
inside catch{} block you can access any exception thrown from services. So in the example, I demonstrate it as a forbidden route, so you can add your conditions and act accordingly.
We covered Service Call Management and Service Error Handling with Redux-Saga.
With the help of callWrapperSaga() we had our service calls centralized.
Hope you find this helpful.
Thank you!
Follow me on Twitter!
www.twitter.com/kaankucukx
