Sagas and reducers: order of execution

I supposed that as sagas are middleware they’re executed before the reducers It appears that actually this is not true.

Here’s my example:

1. reducer that stores the returnUrl erases it after the successful login:

[at.LOGIN.SUCCESS]: (state, payload) => {
    // (1)
    const token = payload.access_token
    return state.merge({
      token,
      returnUrl: undefined
    })
  }

1. I have a saga that is supposed to intercept the LOGIN.SUCCESS action and do the redirect:

function* handleLogin() {
  // (2)
  const returnUrl = yield select(state => state.auth.get('returnUrl') || '/')
  yield put(connectSocket())
}

const loginSuccess = sagaDaemon(LOGIN.SUCCESS, handleLogin)

where sagaDaemon is our helper method:

const sagaDaemon = (actionType, taskSaga) => {
  return function* daemon() {
    while (true) {
      const nextAction = yield take(actionType)
      // (3)
      yield fork(taskSaga, nextAction.payload, nextAction.meta)
    }
  }
}

By placing debugger statements in places (1), (2), and (3) I see, that first the reducer is called, then the master saga gets the control, and then the forks task saga.

So, questions:

• it this behaviour determined?
• is it possible / could it be possible to control it?

In many cases we actually want our sagas to happen after the reducers (currently we ensure this with short delay effects), but certainty is needed. In this particular case the order is not a big deal (I will refactor it slightly), but again I’d like to know that the observed behavior is guaranteed (or how to deal with it if it’s not).

[yelouafi]

the middleware first hit the reducers then after dispatches to sagas. Since reducers are always synchronous the answer is yes sagas always take actions after the reducers.

The order of what happens after is entirely defined by how you implement your flow. In the example above the master of course takes the action first and then forked task

[yelouafi]

Should certainely be mentioned in the docs