Saga pattern?
Redux-saga, what is it and why we use it?
Sagas, was introduced from Hector Garcia-Moline and Kenneth Salem from Princeton University in 1987 so fairly recent concept. Before discussing about redux-saga, I want to introduce the terminology, “Saga pattern”, itself and a little background of its birth.
Imagine we are trying to log you into our system. First of all, we will find the username in the database for you and check the password. If it is all matched, then return the information requested from the earlier request. What I just explained need database transactions and this type of transaction is called Long-Lived-Transaction. However, the problem occurs!
What if our service was largely scaled and had multiple application servers running? While the first server is doing the work, other server may come in and try to use the currently being processed data and will cause issues. We have come across a similar term as a semaphore or a locking in operating systems but basically, the problem is concurrency control.
The pattern is used for Ling lived transaction in the database in order to process distributed transaction in MSA. Basically, saga is a sequence of local transactions.
As you can see it in the image, as a service’s request with saga pattern prevents side effects and completes its job with saga pattern. Therefore, saga pattern is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step.
Now back to React. redux-saga is a library that easily manages application’s side-effects(asynchronous data request, browser-cache, any impure requests) and effectively executes with simple tests for precise failure logs. In doing so, saga uses generator function in javascript.
Saga receives yields from generator and executes another function. Saga yield pure objects called effect that contains command and a middleware translates these commands and executes them, returning the results back to the saga.
Let’s explore the terminologies a little bit further. Saga yields pure objects called effects. Effect is simple javascript object that contains commands that will be executed by a middleware. What are these commands? Commands involve actions like invoking asynchronous functions, dispatching an action to the store, etc. Redux-saga provides some helper effects wrapping internal functions to spawn tasks when some specific actions are dispatched to the Store. This is called an Effect creator and using call, put, we can create effects.
It is very hard to still understand the the whole redux-saga so let’s take a look at the codes and how it is being used!
In order to use redux-saga, we just simply have to create a saga middleware and create a store containing the middleware.
Now, we create a root saga which will wait for the actions to be taken.
This root saga will control the saga pattern by getting the actions from generator and communicate with the store.
This is how action is being dispatched to root saga. First, with the yield call, we are basically waiting for a promise or a function to be complete. Then we have a put which basically dispatches an action to a root saga. Pretty simple.
Saga, by listening to the actions, enables developers to see uniform results limiting the side effects. Redux-thunk is also very useful by allowing asynchronous dispatching actions however, they do not return uniform results. Sometimes, the results are plain objects sometimes the other actions. Saga, by being a listener, will resolve the issue by limiting the side effects.
