This course has been updated! We now recommend you take the State Management with Redux & MobX course.

Check out a free preview of the full Advanced State Management in React (feat. Redux and MobX) course:
The "Introduction to Sagas" Lesson is part of the full, Advanced State Management in React (feat. Redux and MobX) course featured in this preview video. Here's what you'd learn in this lesson:

Sagas allow you to separate the asynchrony from your user interface.

Get Unlimited Access Now

Transcript from the "Introduction to Sagas" Lesson

>> Steve Kinney: All right, so let's talk about sagas. So, thunks let us cheat by dispatching a function that eventually dispatches an object. With a saga, we set up a generator function to intercept the dispatched action object. So we get an action object, cool, then we pause, we send the network request, we wait for it to come back.

[00:00:22] And then we pick up where we left off and dispatch a second action that has all the data that we need. So as far as our user interface code is, as far as a user interface code knows, it's just regular actions as if we were writing synchronous code.

[00:00:34] The saga gets in the middle, handles all of this for us. So now we can test the button to see, did it trigger a fetch all items action? Cool, and you know that for the items list, you can dispatch a fetch or a received all items action. And you can test those just as easily as you tested that Redux code in the beginning.

[00:00:56] And you don't have to mock out stuff. You can just basically I have this one action, I wanna make sure when the button gets clicked that happens. I have this other action that when I give it to the list it should rerender, you can write your test really, really easily, right?

[00:01:10] So we separate into these two pieces and that solves a lot of this testing issue for us. Again, I'm gonna argue that it does add a certain amount of complexity over just dispatching a function. You've gotta choose, you've got make your trade-offs and decide what you're cool with.

[00:01:28] So here, these are the two actions we just wanna make sure we break stuff up between the requesting and the we got it. Right, or the error state, I guess, is a third one that we'd have to worry about. So let's look at it in the dev tools.

[00:01:41] So here we'll hit Request New Friend, you can see two actions fire. We request a friend, and then we add the friend to the list, right? So, one is sending the request, two is when that request resolves we then add it to the UI. These are both UI specific, and they're agnostic of the network.

[00:01:58] All right, there is something kinda in the middle, but you can see we can fire each one of these and they happen kind of in a pair, right? And this is my Offices and Dragons app, which uses the random user API and then assigns them some kind of level and class and hit points and mana.

[00:02:13] I don't know what I was thinking, yeah, so [INAUDIBLE] this is actually a real API. Before, we used a database to mock it out. This is a legit API that we hit and then we decorate with some extra stuff. All right, so in this video what happened? The user clicks on Request New friend, that button fires a REQUEST_NEW_FRIEND action object.

[00:02:37] The saga, which we haven't discussed yet, the black magic in the middle is listening for any REQUEST_NEW_FRIEND objects. When it receives it, it's like, I know what to do. I'm gonna send a network request, when that network request comes back, so it basically pauses. It works with generators, but pauses.

[00:02:55] It waits for that network request to come back, and then it picks up and fires the subsequent one. So it basically is a way to stop, pause, wait, okay, go forward and do the next part of this, right? So it does involve certainly breaking up our actions into two steps, but that makes sense, right?

[00:03:12] Cuz there i that situation where the Internet goes down or the random user API rate limits us and then we fire it off. All right, so, how do we set this up? This is, yeah?
>> Speaker 2: So, when you say, supposing is there is a reducer that's listening to the action still catches it or it actually doesn't receive that action?

>> Steve Kinney: So the reducers will still receive actions, right? But you wouldn't fire the subsequent one, unless you heard back, right? Yeah, as far as the rest of redux is concerned, we set up the saga, it sits in the middle. Trying to listen for these actions and it will start to do things but the rest of our code is really agnostic of any of this a sync Tom Foolery.

[00:03:59] Which with thunks it is definitely like in there, right? Our actions file will look synchronous just like it was before.