Redux is difficult to reason about because side-effects can be triggered from anywhere in the application by middleware.
If you're using something like redux-thunk, a single dispatch can cause both a store mutation AND trigger a side effect, which is confusing. I'd rather have those be 2 separate concerns.
Those dispatches can be triggered from anywhere in the app, and multiple middlewares may trigger multiple side-effects in new and exciting ways.
I find that logic to be difficult to follow and test.
I wish it had a more opinionated way to do side-effects, but the solutions like redux-saga seem even more complicated and confusing.
yup. Its like i said: redux is simple. Middlewares are what makes it complicated.
Redux-loop had a nice model for side effects, but the syntax did not mesh well with javascript limitations. Redux-saga is nice for testing, but it adds new non-standard concepts on top of generators that make it complicated. I really like the Netflix solution (redux-observable).
Since JS is not Haskell, side effects can be shoved to the side a bit, but there aren't a whole lot of ways to make them nice.
CycleJS probably has one of the better systems. In Redux, even without redux-observables, if you closely follow redux semantics I find that reasoning around thunks works quite well (if you're making sure that your actions are semantic and not glorified setters)
If you're using something like redux-thunk, a single dispatch can cause both a store mutation AND trigger a side effect, which is confusing. I'd rather have those be 2 separate concerns.
Those dispatches can be triggered from anywhere in the app, and multiple middlewares may trigger multiple side-effects in new and exciting ways.
I find that logic to be difficult to follow and test.
I wish it had a more opinionated way to do side-effects, but the solutions like redux-saga seem even more complicated and confusing.