A root Saga aggregates multiple Sagas to a single entry point for the sagaMiddleware to run.
In the beginner tutorial, it is shown that your root saga will look something like this:
This is one of a few ways to implement your root. Here, the
all effect is used with an array and your sagas will be executed in parallel. Other root implementations may help you better handle errors and more complex data flow.
Contributor @slorber mentioned in issue#760 several other common root implementations. To start, there is one popular implementation that behaves similarly to the tutorial root saga behavior:
Using three unique
yield fork will give back a task descriptor three times. The resulting behavior in your app is that all of your sub-sagas are started and executed in the same order. Since
fork is non-blocking, the
rootSaga can finish while the child sagas continue to run and be blocked by their internal effects.
The difference between one big all effect and several fork effects is that the
all effect is blocking, so code after all-effect (see comments in above code) is executed when all children sagas complete, while
fork effects are non-blocking so code after fork-effect is executed immediately after yielding the fork effects. Another difference is that you can get task descriptors when using fork effects, so in the subsequent code you can cancel/join the forked task via task descriptors.
There is another popular pattern when designing root saga: nesting
fork effects in an
all effect. By doing so, you can get an array of task descriptors, and the code after the
all effect will be executed immediately because each
fork effect is non-blocking and synchronously returning a task descriptor.
Note that though
fork effects are nested in an
all effect, they are always connected to the parent task through the underlying forkQueue. Uncaught errors from forked tasks bubble to the parent task and thus abort it (and all its child tasks) - they cannot be caught by the parent task.
On the other hand,
fork effects in a
race effect is most likely a bug. In the above code, since
fork effects are non-blocking, they will always win the race immediately.
In practice, these implementations aren't terribly practical because your
rootSaga will terminate on the first error in any individual child effect or saga and crash your whole app! Ajax requests in particular would put your app at the mercy of the status of any endpoints your app makes requests to.
spawn is an effect that will disconnect your child saga from its parent, allowing it to fail without crashing its parent. Obviously, this does not relieve us from our responsibility as developers to still handle errors as they arise. In fact, it's possible that this might obscure certain failures from the developer's viewpoint and cause problems further down the road.
spawn effect might be considered similar to Error Boundaries in React in that it can be used as an extra safety measure at some level of the saga tree, cutting off the failing feature and not letting the whole app crash. The difference is that there is no special syntax like the
componentDidCatch that exists for React Error Boundaries. You must still write your own error handling and recovery code.
In this implementation, even if one saga were to fail, the
rootSaga and other sagas will not be killed. However, this can also be problematic since the failing saga would be unavailable for the app's lifetime.
In some cases, it may be desirable for your sagas to be able to restart in the event of failure. The benefit is that your app and sagas may continue to work after failing, i.e. a saga that
yield takeEvery(myActionType). But we do not recommend this as a blanket solution to keep all sagas alive. It is very likely that it makes more sense to let your saga fail in sanely and predictably and handle/log your error.
For example, @ajwhite offered this scenario as a case where keeping your saga alive would cause more problems than it solves:
If the sagaThatMayCrash is restarted, it will restart and wait for an action that only happens once when the application starts up. In this scenario, it restarts, but it never recovers.
But for the specific situations that would benefit from starting, user @granmoe proposed an implementation like this in issue#570:
This strategy maps our child sagas to spawned generators (detaching them from the root parent) which start our sagas as subtasks in a
try block. Our saga will run until termination, and then be automatically restarted. The
catch block harmlessly handles any error that may have been thrown by, and terminated, our saga.