question: side-effects and dispatch

in this section of the doc on side-effects, it shows something like:

import { sendAnalytics } from '../analytics';
import { doFoo } from '../api/foo';

export function userDoesFoo() {
  return {
    type: DO_FOO,
    promise: doFoo(),
    meta: {
      onSuccess: (result, getState) => {
        const userId = getState().currentUser.id;
        const fooId = result.id;
        sendAnalytics('USER_DID_FOO', {
          userId,
          fooId,
        });
      }
    }
  }
}

in the above sample, sendAnalytics looks a lot like an action creator (with type and payload as args), but submitting actions to redux requires a reference to dispatch somewhere.

is the implication that sendAnalytics submits a redux action, and if so, what is the implied strategy for obtaining a reference to dispatch?

or maybe, i’m asking the wrong question, but my general question is:

what would be the idiomatic way to manage a side-effect with redux-pack that wants to submit another redux action?

or is that an anti-pattern that redux-pack is specifically attempting to avoid?

apologies for being dense, i admittedly struggle with extracting “best practices” for side-effects from related discussions…

my immediate use-case is: on the failure of a data-fetch action i want to submit a subsequent ui-centric action concerned with managing errors (e.g. notify the user visually of an error)

[duro]

@icopp and @tony-kerz:

Based on the following in this projects README, I have a feeling the author considers this an anti-pattern:

Async actions in redux are often done using redux-thunk or other middlewares. The problem with this approach is that it makes it too easy to use dispatch sequentially, and dispatch multiple “actions” as the result of the same interaction/event, where they probably should have just been a single action dispatch.

This can be problematic because we are treating several dispatches as all part of a single transaction, but in reality, each dispatch causes a separate rerender of the entire component tree, where we not only pay a huge performance penalty, but also risk the redux store being in an inconsistent state.

redux-pack helps prevent us from making these mistakes, as it doesn’t give us the power of a dispatch function, but allows us to do all of the things we were doing before.

Given this encouragement, I was able to take a step back and look at our case where we thought a dispatch side-effect was needed, and see how it could be combined into a single action.

[YaaMe]

Why not move it to middleware? like that

export const analyticsMiddleware = store => next => action => {  
    switch (action.type) {
        case DO_FOO: 
            const { meta } = action;
            const lifecycle = meta ? meta[KEY.LIFECYCLE] : null;

            switch (lifecycle) {
                case LIFECYCLE.SUCCESS: store.dispatch(SOMETHING_SUCCEEDED); break;
                case LIFECYCLE.FAILURE: store.dispatch(SOMETHING_FAILED); break;
            }
        default: ;
    }
    return next(action);
}

😛