Transcript from the "Setting up Sagas" Lesson
>> Steve Kinney: So there's some pieces to this. We can import our SAGA file. That's a local file that we made which is going to contain all of our SAGAs. We haven't seen that file yet, we will subsequently. We create the SAGA middleware, we add it to our middleware array.
[00:00:21] And then, if you look at the very bottom, in the same way when you saw that code that was effectively a way but not a way. And we have to kick off the generator. We have to do the same thing with our sagaMiddleware. We have to kick off the generator, so it can start running and pausing and stuff along those lines.
[00:00:37] All right, what does the saga look like? So here's a really simple one. A root saga is this base generator, it's going to theoretically, it can yield back an array of all of the other ones, right? And so, by calling virtual user from API, that generator is kicked off, right?
[00:00:55] We return a generator object and it's going to use all of these, so we had more things going on, we have more things on array. Okay, so then in the middle. All right, we see we have takeEvery, and takeEvery comes from redux saga and it's saying every time a REQUEST_NEW_FRIEND action comes through the pipeline, I would really like you to go make an APR request, right?
[00:01:22] So we say, every time you hear one of these, every time, keep listening for all of these different actions. Every time a request new friend comes along, fire an API request, cool. Make API request, make CAPI request, and then fires that second one. And there's some strange syntax here where you can see that we're using call and put, and that's effectively because that's handling the pausing and kicking off of the generator, right?
[00:01:57] So instead of saying Api.requestnewfriend.then, it is effectively doing that thing that we saw before on that code example where I made the API request, it resolved, and then I kicked the generator back off again. It's doing all of that for us, right? So we don't have to manually do that cuz that code was not the proudest code I've ever written in my life.
[00:02:15] And when you see ugly code, you can either own it or you can abstract it away in a nice, pretty shell, and just make believe that the messy bits of your code aren't there. And so this library will extract, kicking the generator off when the promise resolves for us.
[00:02:31] So we call the Api.requestNewFriend. When we get that back, we can go ahead and we can put which is dispatch effectively that new action, all right? So I'm gonna do an example inside of Jet Setter. Now Jet Setter's got a lot of things going on. I'm just going to replace one of the actions.
[00:02:57] The nice part about sagas and thunks is that like other things we've talked about, you can use both of them. All right, you can mix and match. You don't have to be like I'm all about sagas or I'm all about thunks. If there's a thing where saga is a better solution to the problem for you, do that.
[00:03:13] But if thunk is a perfectly fine solution and you want the simplicity, go do that, right? It's up to you to kinda make these decisions which I know it's unfortunate that I don't have a perfect right answer for you, but it does mean that you have the flexibility.
[00:03:29] The reason they pay us the big bucks is cuz if this was easy and there were rules, it would just be data entry and nobody would pay us to do this stuff. So unfortunately, the reason that we're all doing this for a living is because we have to make these hard choices.
[00:03:44] All right, give me one second to set up.
>> Speaker 2: I have a question.
>> Steve Kinney: Yeah.
>> Speaker 2: Can we get an example of where you would want to use a saga over a thunk?
>> Steve Kinney: Yeah, I think a lot of it, for me, comes down to testing, and a separation of all this network stuff.
>> Speaker 2: It's adjusting to that case.
>> Steve Kinney: Yeah.
>> Speaker 2: Okay.
>> Steve Kinney: So that's the kind of the biggest example, but it is definitely, there is like a lot more ceremony than just simply dispatching an object, right? So it is like, if you know in the application I work on in a day to day basis, we actually do surprisingly little async.
[00:04:16] The API just happens to give you everything you need, whether you want it or not almost to a disturbing degree. So once we have everything, we basically then saving that object all over again. So we're basically doing one way in the editor. There's one async action. So for us, I don't know if it's worth the amount to put in place like setting up that one mock is not that bad.
[00:04:39] But if we were doing something where there's a lot more data going back and forth, if we're building a very high network IO app, then that's all of a sudden, the cost benefit analysis switches rapidly, right?