Implement Asynchronous Side Effects with Non-Blocking Saga Effects
When we need to run side effects and do not care about a return value, we should use non-blocking effects. This way we can iterate through our sagas as efficiently as possible. Some popular non-blocking effects are put and fork.
Instructor: [00:00] Let's import select, throttle, fork, spawn, and cancel. These five effects, as well as put, are considered non-blocking effects. This means that they're used inside of our saga generators.
[00:13] The generator will continue to iterate through without waiting for a resolved value. On the other hand, call is blocking because we need to wait for a return result to use inside of our put. Let's do const selector = yield select and a function.
[00:31] Here, we're using the select effect, which will instruct the middleware to invoke the provided selector on the current store state. Ideally, we would create the selector method elsewhere and import it at the top of this file.
[00:45] We can see this in action by console logging the selector. Now, if we open up our UI and click on our "Load more" button, you can see that we get there our state at the time before our call is made and our put is dispatched.
[00:56] If we move this down to the bottom and now try it, you can see that now we get our reducer with our results. Let's remove our select effect. We'll paste in two new generator functions.
[01:15] Sometimes, we need to throttle actions that are dispatched. A common example is when a user is typing text into an input box. Throttle has three parameters. The first is a time in milliseconds.
[01:27] The second is a pattern or the type of a dispatch action creator. The third is a generator function. Here, we're basically saying once input change is seen, we will not spawn a new handle input saga until this amount of time is satisfied.
[01:45] Now, let's remove these generators. Back inside fetch person, we do yield fork API and a URL. Fork does the same thing as call. The first parameter is a function. The rest of fork's parameters are spread out into this first function parameter.
[02:01] However, the difference is fork will call the API with this URL and then continue on through the saga without stopping or blocking the rest of the effects. This is handy when you need to send a request but don't need the return data.
[02:15] Even though fork is non-blocking, the fetch person saga will not return until all fork tasks come to a resolution. Spawn is similar to fork. However, it creates a detach task.
[02:29] These remain independent from its parent and act like top-level tasks. Fetch person will not wait for the spawn task to terminate before returning. Also, all events which may affect the parent or the spawn are completely independent.
[02:45] Let's do const dogs. We'll do yield take canceled as well as yield cancel dogs. We'll paste in this canceled action creator. Once fork tasks are initiated, we may need to cancel them.
[03:00] By using this take, we are saying after we've called in put, if we see this cancel action creator, we need to cancel the in-flight request if it's still pending. Cancel will stop the effect it's provided wherever it's at.
[03:14] This is handy when someone is logging into a site and after clicking "Log in," they instantly click "Logout" or "Cancel" before the response is returned. This can be used in both spawned and forked tasks.
Why didn't Tyler demonstrate the last 30 seconds of this lesson? It would have been far more effective. In any event, I think he said "fork" when referring to "spawn"