Using functions in observables vs creating many actions/epics - redux

Question

I'm just starting to use redux-observable and I'm having trouble deciding between multiple ways to do the same thing. Here is a contrived example of two ways to execute some logic in response to actions:
Method A (epics):
function epic1(action$){
return action$.ofType(FOO)
.map(action => something(action.payload))
.map(result => ({type: BAR}));
}
function epic2(action$){
return action$.ofType(BAR)
.map(action => something(action.payload));
// potentially returning actions for a third epic, etc.
}
Method B (functions):
function helperFunction(result){
// something that returns an action eventually
}
function singleEpic(action$){
action$.ofType(FOO)
.map(action => something(action.payload))
.map(helperFunction);
}
You can imagine each pattern scaling out and the functions being realistically complex. Is there a lot of overhead to doing Method A? Are the actions going to go through the entire redux loop before arriving at epic2 and is this something that has been noticeable in anyone's experience?
I definitely want to make as many things epics as possible so far because they've ended up being really small and simple, but I'm not sure about the costs.

Answer 1

I can offer my experience from a project using redux-saga. I think the performance characteristics and design trade-offs are quite similar.
It is likely that there will be some performance hit in case A. However, unless there is something really wrong, it should not be a big consideration for your average SPA. YMMV if you're developing games or something else performance intensive. From this point of view creating fewer sagas seems like a micro optimisation.
We were leaning very much towards something similar to what you describe as method B. We would typically create factories for families of similar sagas, pretty much like in the following example:
const factory = ({ actionType, mapper, actionCreator }) => (action$) =>
action$.ofType(actionType)
.map(action => mapper(action.payload))
.map(actionCreator);
const epic = factory({
actionType: 'FOO',
mapper: payload => payload + 1,
actionCreator: newPayload => ({ type: 'BAR', payload: newPayload })
});
It probably does not make all that much sense in this contrived example, because the cognitive overhead of the abstraction is higher than what you're getting from it, but you get the idea. We employed a very similar strategy for reducers, too.
However, when possible, I would warn against creating waterfalls of actions like you describe with epic1, epic2, etc. I believe that if you have too many of those implicit interdependencies in your code, it will eventually be more difficult to debug. Though probably nowhere near as hard as chains of two-way bindings in some frameworks of the past (Ember, for example).
So in general, my recommendation would be to create as many little sagas as you like, creating little helpers to help you construct them. But prefer longer more explicit epics for more complex asynchronous flows (as opposed to having too many collaborating epics).

Answer 2

Method A will be slower because it is going through the whole redux chain of reducers and epics. (epics are essentially middleware). How slow that is, and how much that matters depends on what you think is more maintainable and clear to understand.
I think that, if you have a FOO action, that should perform some helping functionality, and eventually kick off another epic, that you don't need three separate epics. It makes much more sense to me to not kick off any subsequent actions if possible.
However, if you do need to merge epics, then creating one epic that handles a 'waterfall' type flow would make sense. For this contrived example, I would definitely not do Method A. If you just need to run some side logic, then call the function directly. There is no need to walk upstream, so you can ride down a river, so you can be where you already are.