 I am working as a mobile developer at Curve Tomorrow. It's an Australian based healthcare startup. My topic for today is less angry asing. But before I go there, I want to tell you a story. Once upon a time I was working with an Indonesian startup, a woke private limited. It was basically a startup like Paytm but for Indonesia. So the user had a wallet balance and using that balance he could do different activities like selling off recharges, doing insurance services and different things. So these are near the dashboard. So I started researching the best practices using which we can make the dashboard because dashboard involved hitting many APIs and then getting the response of all the APIs and then showing it together on one component. So my first attempt was I started making one function at a time so I was creating function for everything, every API and then putting everything inside one component but then I realized that my component is becoming really complex and it's really difficult to understand the code and I have more bugs in my component than the features. So I was looking for something which is more modular and then which has a cleaner approach to fix this. So I continued my research and then I came across Redux. Basically I knew that in my application I needed the state in multiple places, the same state will be required in multiple places, multiple components. So Redux is something which gives us that. So I said that okay I'll go with Redux as an architecture and then I was still looking for something to handle side effects that is hitting the API calls, how can I make that possible in Redux. Then I wanted some solution which is more readable and we were very much focused on testing so it should be easy to test as well. So first I started understanding the Redux architecture, basically you have a component which will dispatch an action for anything it wants to do suppose it wants a user data. So you say get me the user data that will become an action and that goes to Reduser and the Reduser will process it, gives the new state back to the store and then store will give it to the component and component will get the user data and then it will update itself. So component is always listening to store, as soon as the store gets updated the component gets also updated. That's like a, you can say high view of Redux. After that, after I got into Redux I was looking for the solution for handling the API and I came across two libraries, that time Redux Thunk and Redux Saga. So I had to look into Redux Thunk, basically you get rather than dispatching a normal action, your normal object, your action can return a function which has access to dispatch and state. So you can wait for some time you can hit the API and wait for some time and then you can dispatch any action you want and you can also get access to the state. But the problems with this were like as I had to perform more and more complicated operations like suppose one of my APIs waiting for another API to return the response, I was falling into the callback hell and the code was becoming really difficult to read and also the testing was too complicated. So I was wishing like what I want to do is I want to execute the hell function which you know can execute the API hitting task for some time and then wait and then again after some time it should continue the next task. So I was thinking like if there should be something which you know which run and then wait and then run again. So then I came across Saga so Saga is basically that it gave me the control over hitting the API and then waiting and then executing the next function. It is basically a library middleware which handles the data fetching and data fetching and impure things task and then and it also makes your application really easier and the code is really easy and you can understand it by looking into the code. So how does it does it that it uses the ES6 generator functions and it has something called SagaFX. You can consider it as a methods or instructions to middleware and my action remains pure like Saga are really different you have it in a separate file so your action remains pure. So I am going to talk about all this in a bit. So I was really excited for my journey so I hope you are too. So let's start the journey. So back to the problem I had to create the dashboard right so I would add the required hitting get user load balance load banner and transaction details. So first it needed the get user and then all the other APIs were depending on the get user response. So first need it as Saga user generator I had to learn the gender basics so I started writing understanding it. So if you see this function normally whenever we have a generator function what we expected to return the inside whatever it's there inside or anything but as Saga's are different whenever you encounter a function within star it's a generator function and for now just don't focus on the E so when I should run this function I should get the console log but as generator are different when you run them it returns something called iterator. So you can iterate over your functions you can say. So I am writing the get people function and I am getting people that's an iterator and if I want to iterate over this I will have to use .next. So when I do .next on this iterator I get the response and an object which tells me value which means that statement has anything to return and that means if I have more code to execute. So if you see I didn't get the second console log because there is a yield in between yield means pause. Pause at that execution until it calls .next again. So if I want to execute the next part I will have to call again .next on that iterator so I will call it and I get the response and if you see the object it says done is equals to true that means your function is completed. So that's how you understand how generator is working. Then I started writing the reducer so I wrote the dashboard reducer and I was looking into basically I wrote the simple reducer that whenever you get dashboard success action whatever statement is given you update the state so that my dashboard gets updated and I was looking into where the sagas lives actually in the forward base so that's you can see there. In the architecture I wanted to look like how the sagas are related with the redux architecture. So basically when your component dispatch an action your reducers are listening to all the action same way your sagas are also listening to the action. So whatever action you dispatch the sagas can listen to it and perform any operation so we will see in a bit. So I spoke about saga effects how that how saga does that how it listen to everything and performs is basically using saga effects which are basically the instructions to the middle web. So I started learning more about it. First take every and take latest. So whenever an action gets dispatched I want to know about it. So you can use take every to listen to every action it is getting dispatched. It basically has the first argument which takes the action and the second one is fetch user which is basically a method we're dealing with hitting the API and getting the response. So that's an async method. So I'm doing that take every and every time and this fetch user requested action gets dispatched all their methods. And the take let us will do the same but what is the difference here is whenever suppose I'm dispatching fetch user requested my API is running and I'm dispatching again the fetch user requested in case of take latest it is going to cancel the previous one as you see in the diagram. So it will always return you the response of the latest request. So that's the difference between them. Then I look at take is basically take every and take action or continuously listening. But if you want more control over listening to the action you can look into you can use take. Basically take only the single action and then it stops. So you can use it in different ways put the same like this patch it dispatches action get gives you like the state you can access the state using select sorry you can access the state using select so let's see the example how this is working. So suppose you have an example where you user has created 2dos and after creating 3dos you want to show a congratulation message to the user. So if you look into the code I'm putting what I want to do here is I want to take an action which is to do created and I want to take it for 3 times so I put it inside of all loops. It will basically wait until these I've received the action for this 3 times. After I've received it I'm selecting the state from the store and then user because I want to know which user it is and then I'm putting it into the I'm using put dispatch the action to the store that I've shown the congratulation message to the user. So that's how it works. If you look into the code it's really easy to understand by looking into the code what exactly is happening that's one of the advantage of salas. So there were more effects. Suppose you want to run an API so basically to run an API function which has an async task in it. So you use two effects which is one is call and one is folk. So call is basically blocking and focus not non-blocking. Let's see the example and we'll get more into this. So in this example what I want I'm doing is I'm taking a login request it's a very common example. We have a login request and the user is getting logged in but I'm doing that call and I'm passing the authorized method which is responsible for hitting the API and getting the response and after that I can pass the parameters whatever I want to the call method. So if I use call it will not move to the next line until it is finished execution hitting the authorizing API. During the same time if suppose user changes his mind and he wants to log out to the app the component will dispatch a logout action but as it is blocking it will ignore the logout and it will not be into a good state. So if you want to deal with such things you use folk instead of call. So folk is non-blocking so if you will use folk in this case the folk will create a new thread in which the authorized function will get execute and it will call the API it will get a response and in between the logout it will go to the next line and wait for the logout action to come. As soon as the logout is coming in between it will logout the user and clear whatever you want to do after that. So that was like the basics of saga effects which I got and then I registered the saga into the like I created a saga I needed two sagas for this the load user and then that dashboard now you say a lot about show me the sagas how you wrote the load user and the dashboard so let's look into the load user so what it should do basically is I should call the get user API and then any time you once you get a success response it should dispatch a success method otherwise the failure one so that's what we are doing here we want to wait so yield is wait for get user to finish and I am making it a blocking one then call I told you that is a blocking effect then once I got the response I am dispatching the put is dispatching the fetch user success action and then if I got any error in between I am dispatching failed action this was quite simple the complicated version was the dashboard one where I had to get first I wanted to wait once the user dispatches you fetch user success is being done I want what I wanted to do is hit three APIs get the response of it and then show it to the user so that's what I am doing here so I would like yield take wait for the fetch user success action once you get it select the user state from the store then call three different APIs call first load balance because load banner and load banks all these APIs were dependent on the user so pass the user to them and once you get all the three responses you dispatch an action that I got all the data and update the dashboard so this was like the if you now look at the code it's really simple when you look if any other developer will come and look into your code just by looking at it they will understand what exactly is going on so that's an advantage by we like using servers so and I was thinking that's fine I am using call there but in any way I can make my previous example any better so I came across one more effect which is all so as all the three calls load banner balance and transaction details doesn't have to wait for each other to finish so what I did is I put everything inside yield all and now all the three will start executing at the same time and once everything gets finished I get the response and it will go to the next line and dispatch an action to the dashboard I've got all the state you just update yourself update the component so you will say yeah I get it you get the readability but what else what is the other advantage of using server so there's one more thing which is which is which I like really a lot which is task cancellation as a developer you have to phase a lot like suppose you have started some tasks due to some reason you want to you know cancel the task so if you are into like into a callback hell it is really difficult to identify which task you want to cancel so let's see the example how task cancellation happens in servers suppose I start a background sync task and in like every day it should sync at particular time which is like very common use case these days so after that once it starts syncing sometimes if suppose user logs out or do any event I want to cancel the syncing so how will I do that in servers so I'll wait for background syncing task action to happen once I get that I'll start the fork remember the fork it's non-blocking so I'll start the background sync in the background and then it will go to the next line and it will wait for the background syncing cancel once it gets it gets the action that he canceled the background syncing the fork basically returns you the task so you can store it in a variable and then all you have to do is just cancel that background as here I have stored in background sync task so I just cancelling that and not only that whenever you cancel this task so if you see this pg sync generator method whenever I get cancelled I'll get an event there in the finally that hey you got you got cancelled if you want to do any cleanup you can do that in that so that's really really useful so that's it that's all about saga but what about testing so we like we want to obviously test this and as I said that testing is really important so when you want to test it's really easy you have to remember these rules and then it becomes really easy so what you have to do is as I told you that generator generator doesn't return to so you store a generator into a variable and you call the next method on it then it will return you an object with a value and done equals to false take that value and just use expect and compare what you are expecting it to be and if done is true that means you have reached to the end and then you don't have to test anything more so let's consider the dashboard scenario which we saw earlier so in this I'm just going to test the first one that whenever a fetch user success gets dispatched my generator should yield a take effect so let's see that so as I said the first rule is store your generator into a variable then call dot next on it take the value you have the actual value which will be a take effect that's the advantage here the effects are basically what they return is an object which are like instruction to middleman so you can directly compare the effects value and with the expected like here I'm expecting a take effect I can write that and just compare it like that you can expect all the effects with proper value parameters and then test your scenarios so that's it I'll just want to conclude here that suppose you have a complex if you don't have too complex flow there's no need to go with redux saga you can do your things with redux using redux thongs as well but if you want to if you have very complicated flow and you are dealing with a lot of ABI calls which are interdependent you should definitely try out redux saga there is a learning curve when you are dealing because you have to understand a lot of how they are working but I think the stock would have made it a bit easier so in any case you should write your test if you are not writing because writing test is really important and if we have a testing BOF as well so if you are interested to know more about it you should definitely join that's it thank you everyone for your time