The beauty of redux itself is the lack of magic. It's essentially just a design pattern and is trivial to follow.
So the "edit" part of your comment is key here: frameworks built on top of redux, including middlewares, store enhancers and stuff can definitely lead to an app that is hard to reason about with side effects happening in places you don't expect.
IMO that ends up being the worse of both world: even with all that tooling, Redux is far from terse (in favor of being explicit), but you also get the drawback of a deeply layered framework. This isn't worth it. There are other frameworks and tools that do this better. If you want to be terse, and don't mind throwing in a lot of layers on top of your code to achieve it, use one of the countless other (mainstream!) solutions to do so.
Redux really excel at "putting the code in your face", giving you easy to follow logic where very little is abstracted (and when it's abstracted, it's just via simple function composition). And at doing that, it is amazing and is my pattern of choice. At anything that diverge from that though, it is so bad it's not funny. Right tool for the right job :)
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)
Comments
The beauty of redux itself is the lack of magic. It's essentially just a design pattern and is trivial to follow.
So the "edit" part of your comment is key here: frameworks built on top of redux, including middlewares, store enhancers and stuff can definitely lead to an app that is hard to reason about with side effects happening in places you don't expect.
IMO that ends up being the worse of both world: even with all that tooling, Redux is far from terse (in favor of being explicit), but you also get the drawback of a deeply layered framework. This isn't worth it. There are other frameworks and tools that do this better. If you want to be terse, and don't mind throwing in a lot of layers on top of your code to achieve it, use one of the countless other (mainstream!) solutions to do so.
Redux really excel at "putting the code in your face", giving you easy to follow logic where very little is abstracted (and when it's abstracted, it's just via simple function composition). And at doing that, it is amazing and is my pattern of choice. At anything that diverge from that though, it is so bad it's not funny. Right tool for the right job :)
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.
You should checkout https://github.com/jumpsuit/jumpstate
It's much easier to reason about, including side effects, while not being too magical.
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.