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)
Comments
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)
+1 for redux-observables, I've found RxJS to be an excellent tool for managing async without going insane.
I'd also second the notion to be rigorously consistent in following the semantics. I always end up regretting shortcuts.