These are chat archives for jdubray/sam
Here is the core of the argument:
Methods for handling effects in Redux, especially those implemented with action-creators, incorrectly teach the user that asynchronous effects are fundamentally different from synchronous state transitions. This separation encourages divergent and increasingly specific means of processing particular types effects. Instead, we should focus on making our reducers powerful enough to handle asynchronous effects as well as synchronous state transitions. With redux-loop, the reducer doesn't just decide what happens now due to a particular action, it decides what happens next. All of the behavior of your application can be traced through one place, and that behavior can be easily broken apart and composed back together. This is one of the most powerful features of the Elm architecture, and with redux-loop it is a feature of Redux as well.
Now, I am suggesting that there is no need to separate effects from the business logic, it is better to spend your energy factoring the business logic around "mutating" state (the correct way). what a strange idea! You have state, all you do all day is mutating it, and some people focus all their energy on effects and abstracting state away? really?