[tracker1]

The community seams to be using action creators combined with either redux-thunks, or redux-promise...

I have simple action creators that are simple actions, where the reducers only update state... actions creators will do anything more complex...

    export const doSomethingAsync = input => async (dispatch, getState) => {
      try {
        dispatch(updateStatus('loading'));
        var response = await client.get('...');
        dispatch(updateStatus('success', response.data));
      }catch(err){
        dispatch(updateStatus('failure', err));
      }
    }

I prefer the redux-thunks with async functions, as this lets me be more explicit and do a bit more work, if I need more status levels than loading/success/failure modes. This is a relatively simple example, and pretty close to how the defaults for redux-promise works...

There's no side-effects to having your async calls inside your action creators... Well, there's a chance that an intermediate action may be dispatched in between the loading and success, but even then, unless things are very brittle, it's easy enough to mitigate, and that's only for portions of the tree that are shared.

[tracker1]

Okay, it is subject to side effects, since the input from the original method call isn't the only point of intersection/input, the async call is part of it...

Just the same, the exposure is still minimal, and easily testable.