Is Redux using a sanitized God object pattern

Yes this pattern will apply well with redux saga.

Think of redux saga as just a middleware layer within Redux. Basically when you dispatch an action in your code, redux saga will intercept that action and then can be used to do async things like calling an API or modifying data and calling other actions.

So in the case of your example, when you dispatch GET_FOO_REQUEST you should have a listener setup in your saga for that action. Then the saga function can look like so:

1. Dispatch action to toggle loading state in redux
2. Send the API request
   • If successful, dispatch GET_FOO_SUCCESS
   • If error dispatch, GET_FOO_FAILURE

Then in your reducer for GET_FOO_SUCCESS/FAILURE you should toggle the loading state to off and do whatever else you need.

You can write all the boilerplate code yourself, however one cool library you can use is redux-saga-routines, it will automatically create 5 different action types for this purpose:

• routine.TRIGGER
• routine.REQUEST
• routine.SUCCESS
• routine.FAILURE
• routine.FULFIL

Here is an example saga using these action types:

function* callAPI(action) {
  yield put(routine.REQUEST());
  try {
    const response = yield call(api, 'GET', '/foo/endpoint');
    yield put(routine.SUCCESS(response.data))

  } catch(err) {
      yield put(routine.FAILURE(err.message));

  } finally {
      yield put(routine.FULFILL());
  }

}

I will do a guess from different sources.

1. I heard "security is not a crosscutting concern" I would put authentication in it. It can not be separated from the program although not included in the model and then pressed in when needed.
2. Whether you are authenticated is not part of your model in a way that you have two objects, one authenticated and one not authenticated at the same time.

Thus, you try to push authentication as far away from the other logic. You put it in a layer between communication and model. That layer is so thin that you do not give extra space to it in an example as this layer may not evolve or evolve in unforeseen ways in programs building on the example. Besides, there are only two places to handle that use case.

An other one is that in an example, you like to go for simplicity instead of perfection.

PS: An answer like this usually leads to better answers coming. Good luck!