Understanding Generator Functions & Using Redux Saga

hey what's up everyone I'm Homer Nadeem and today I'll be talking to you about generator functions and Redux saga so Redux saga is a middleware that's used in redux to help us get a cleaner more asynchronous looking style of code and it's based on an es6 feature called generator functions so what are generator function so we typically assume that a function will run to completion that generators are a little bit different so the official definition is that generators are functions which can be exited and later re-entered and their context will be saved across three entrances so what this effectively means is that you can sort of pause the function and then restart it later when you're ready and the generators are also cooperative which means that we choose when to pause the function but and it doesn't stop other code from running and then we have to reinitiate it when we're ready so here's a little bit of the syntax and generators are declared using this special asterisk keyword which comes right after the word function and a little fact some call this a super store I only read that on one article and wasn't really able to confirm it anywhere but I thought I'd roll with it and so if you look at this sample code the function foo is declared with the asterisk keyword and there's three separate variables and the function returns the sum of those variables but there's also a special keyword called yield which is specific to generator functions so yield is kind of where the magic happens inside the function and it's used to pause the function and also give out a value and the next time we run the function we can also pass in a value to that yield expression you can also use the ashes with the yield which basically means that it will pause and then delegate its actions to another generator function which will complete and then come back to the original function so here's a little bit of summary of how to run the function it's a little confusing but I'll walk through an example on the next slide so we first invoke the function and we store it in a variable and when we actually run the function we don't go through the code but it just gives us back an object which we can use to iterate through it so on that object you can call next and that it will break at the first yield that you specified inside the function and that object that we returned gives us a value which is what is to the right of the yield expression and done which indicates a true or false on whether the function is completed and we can keep doing this until we're done or stop at any point and it won't affect any of the rest of the code so here's a small example the function foo basically takes in an expression for XY and Z and it'll pause at each yield so here's the actual code when we're running it so we store foo inside of generating foo and then we call next on it and the value we get is asked for a value for x and the next time we run it we can pass in that value so it's a little tricky because the first yield gives out a value and then when we call next on it again we're actually passing in a value to that yield so on the last call that generating done X 25 we store value into Z and we get the final result which is the value 50 and done which is true which indicates that the function is done so this example is a little trivial but I think it helps to kind of understand the mechanics of how the generator functions work so some of the better use cases and what we'll actually use them for our asynchronous functions which call next when the async function is done so an example like this where we use the generator function main and now we started at the bottom and then it hits the first yield which is a request so request is the function at the top which will make an AJAX or actives call and when it's done it'll pass in that response to the generator function so you can split out your async logic into separate functions and still use them inside the generators so they'll basically do your play and pause for you so the main place this is used is in redux saga which is what we'll cover next so in redux you know it handles synchronous actions and we're usually using a redux funk but redux saga is like an alternate to that and it's a little bit better in my opinion so it's a library that aims to make handling side-effects and react redux applications easier and better and you can think of a saga as like a separate thread in your application that's responsible for just the side effects and since it's a Redux middleware it can handle all the normal redux actions and it can dispatch Redux actions as well so it's all based on the generator functions we just covered but the good part is that the middleware handles all of the calling next and the yield and pausing and playing it again so here's some of the boilerplate set up it's a relatively simple you just import Redux saga and you create the saga middleware and mount it on the store in the create store function and at the bottom you run the rootstock so our sagas are split up into two categories which are Watchers and workers this is just convention you don't have to do it like this but it makes it a little bit easier to understand so the watcher sagas basically watch for any action that's dispatched to the store and then they delegate that action or that listening of that action to a worker saga and in that worker saga is where you actually sort of the code and do all your actions those Watchers augers are typically in the main route saga function that you'll export and mount on the store so here's an example on the left some of these keywords are special Redux saga functions which we'll look at next like take every call input but basically what's going on is that the watch get products is listening every time that a get all products action is dispatched to the store and then giving it to the other generator function get all products so instead of get all products we do an API call and store the result of that into products and a puts as a dispatch which does an action creator with the products passed in so on the right hand side is a little bit of a more involved example but it's basically doing the same thing so instead of take everyday wrap this one in a while true loop which is an infinite loop but it's okay with generator functions because they all is in place and inside a check out we select the cart do a call with that cart and dispatch to the store if it's successful and if it's not we'll dispatch the error so this is kind of why I like Redux saga because you can get like a clean flow of exactly what's going on and it's a little bit simpler to understand so you can see that any time there's a checkout request you can go to your worker saga and see exactly what you're doing so these are some of the saga helpers that I mentioned take every basically means that do this work or saga every time this action comes in and take latest does the same thing except that if subsequent requests come in on that same action it'll cancel the prior one so depending on the type of action or setting up you can choose one of these usually to initiate so the ASEC creators are like call and put and take and these effect creators return playing javascript objects but give into the middle where they're like instructions and the middle where's where the actual iteration happens so let's um yeah the middleware examines each effect description and that it performs the appropriate action so the main ones if you're using this library is going to be call input then call is the one we can focus on that it basically does a function and you can pass in optional arguments to it this is where you'll do like your API request and the key takeaway is that if it returns a promise it'll cause the saga until the promises result and you can store that value inside of results and then do a put which will dispatch that result yeah so these are some of the advantages of Redux saga over Redux tunc like I mentioned it's a more synchronous looking code it's sort of a easy to follow step by step process and you can tuck away the synchronicity into a separate part it allows for fairly complicated flows so you can do like a call tour that in a variable and then do another call and then based on that through a dispatch with put and do another call so you can really like layer actions on top of each other and still keep it sort of easy to understand sagas are composable this was basically the yield with an asterisk so you could set up a saga which will then delegate to another saga and run that one to completion then come back to the original one one of the advantages is that action creators become pure so your action creators aren't mixed up anymore like you don't need a function that returns another function that does a call and then another dispatch you can basically just have functions that return pure objects and this what this separation does it makes the side effect code separated to the single area of your application which is the saga stage this library has a lot of helper functions and pretty solid documentation one last bit of peace one last piece is a testing so as we're all moving on to capstone and getting ready for larger projects I think we've been told that testing becomes a little bit more important so the Redux test that we've been writing we're usually only testing the action creators like the synchronous actions but with this it's a little bit easier to test the async code too because the effect creators return just plain JavaScript objects and we can test all of our async calls like in here basically by iterating over the generator and seeing that the value of the next call matches which you had intended and that's pretty much it if you're interested I definitely recommend the Redux saga documentation it's pretty clear and walked through a lot of the concepts really well thanks I real [Applause]

Channel: Fullstack Academy

Views: 84,588

Rating: 4.716814 out of 5

Keywords: Redux Saga, generator functions, generator functions and redux saga

Id: o3A9EvMspig

Length: 11min 18sec (678 seconds)

Published: Fri Mar 17 2017