What is the idiomatic way of starting rootSaga?

Question

redux-saga project has been existing for a pretty long time now, but still there are a lot of confusing things about this library. And one of them is: how to start your rootSaga. For example, in the beginner tutorial rootSaga is started by yeilding an array of sagas. Like this

export default function* rootSaga() {
  yield [
    helloSaga(),
    watchIncrementAsync()
  ]
}

However, in the using saga helpers section rootSaga consists of two forked sagas. Like this:

export default function* rootSaga() {
  yield fork(watchFetchUsers)
  yield fork(watchCreateUser)
}

The same way of starting rootSaga is used in async example in redux-saga repo. However, if you check real-world and shopping-card examples, you'll see that rootSagas there yeild an array of forked sagas. Like this:

export default function* root() {
  yield [
    fork(getAllProducts),
    fork(watchGetProducts),
    fork(watchCheckout)
  ]
}

Also, if you read some discussions in redux-saga issues, you'll see that some people suggest to use spawn instead of fork for rootSaga to guard you application from complete crashing if one of your forked sagas is canceled because of some unhandled exception.

So, which way is the most right way to start your rootSaga? And what are the differences between the existing ones?

Answer 1

You can start multiple root sagas. But any saga has the ability to start another saga on its own. Thus it's possible to start a single root saga, that creates the other sagas.

You just need to be aware of how errors propagate to the parent saga. If you have a single root saga and a child saga crashed, by default the error will propagate to the parent which will terminate, which will also kill all the other sagas started from this parent.

It's up to you to decide this behavior. According to your application you may want to have a fail fast behavior (make the whole app unusable if there's such a problem), or fail safe, and try to make the app continue working even if some parts may have problems.

Generally I'd recommend that you start multiple root sagas, or your parent saga uses spawn instead of fork so that your app remains usable if there's a crash. Note that it's also quite easy to forget to catch errors in some places. You generally don't want, for example, to have all your app become unusable if there's a single API request that fails

Edit: I'd recommend to take a look at https://github.com/yelouafi/redux-saga/issues/570

In this redux-saga issue, I show different ways to start sagas and the impact it has on your application.

TLDR: this is how I usually start root sagas:

const makeRestartable = (saga) => {
  return function* () {
    yield spawn(function* () {
      while (true) {
        try {
          yield call(saga);
          console.error("unexpected root saga termination. The root sagas are supposed to be sagas that live during the whole app lifetime!",saga);
        } catch (e) {
          console.error("Saga error, the saga will be restarted",e);
        }
        yield delay(1000); // Workaround to avoid infinite error loops
      }
    })
  };
};

const rootSagas = [
  domain1saga,
  domain2saga,
  domain3saga,
].map(makeRestartable);

export default function* root() {
  yield rootSagas.map(saga => call(saga));
}

Answer 2

How to create rootSaga?

According to a core developer of redux-saga [1,2] the idiomatic way to create rootSaga is to use the all Effect Combinator. Also, please note that yielding arrays from sagas is deprecated.

Example 1

You could use something like this (+all)

import { fork, all } from 'redux-saga/effects';
import firstSaga from './firstSaga';
import secondSaga from './secondSaga';
import thirdSaga from './thirdSaga';

export default function* rootSaga() {
    yield all([
        fork(firstSaga),
        fork(secondSaga),
        fork(thirdSaga),
    ]);
}

Example 2

Taken from here

// foo.js
import { takeEvery } from 'redux-saga/effects';
export const fooSagas = [
  takeEvery("FOO_A", fooASaga),
  takeEvery("FOO_B", fooBSaga),
]

// bar.js
import { takeEvery } from 'redux-saga/effects';
export const barSagas = [
  takeEvery("BAR_A", barASaga),
  takeEvery("BAR_B", barBSaga),
];

// index.js
import { fooSagas } from './foo';
import { barSagas } from './bar';

export default function* rootSaga() {
  yield all([
    ...fooSagas,
    ...barSagas
  ])
}

fork vs. spawn

fork and spawn will both return Task objects. Forked tasks are attached to parent, whereas spawned tasks are detached from the parent.

• Error handling in forks [link]:

  Errors from child tasks automatically bubble up to their parents. If any forked task raises an uncaught error, then the parent task will abort with the child Error, and the whole Parent's execution tree (i.e. forked tasks + the main task represented by the parent's body if it's still running) will be cancelled.

• Error handling in spawned tasks [link]:

  The parent will not wait for detached tasks to terminate before returning and all events which may affect the parent or the detached task are completely independent (error, cancellation).

Based on above, you could, use fork for "mission critical" tasks, i.e. "if this task fails, please crash the whole app", and spawn for "not critical" tasks, i.e. "if this task fails, do not propagate the error to the parent".