The arguments against Redux (which this article doesn't really make, but still) are very valid - it is a nice abstraction and way to think about data flow, but its simply too much boilerplate.
Almost every Redux example is tons of repetitive code because of this, and that's before you add in middleware, thunk, saga, reselect etc. Yes I know Dan himself wrote a bunch of articles on how you don't really need to use it and how its conceptually simple, none of that changes what most of the libs and code looks like.
I don't have the answer but I can't help but think there has to be a better way to handle this. We had templates and generics decades ago exactly to reduce repetitive boilerplate.
Redux should never have been adopted in its current form. Its exactly the sort of thing that should be handled by a framework/tooling for you. Imagine if for every React component you had to write a custom parser/resolver/reconciler, all of which had 99% common code and just passed params around. That's what redux boils down to.
Almost every Redux example is tons of repetitive code because of this, and that's before you add in middleware, thunk, saga, reselect etc. Yes I know Dan himself wrote a bunch of articles on how you don't really need to use it and how its conceptually simple, none of that changes what most of the libs and code looks like.
I don't have the answer but I can't help but think there has to be a better way to handle this. We had templates and generics decades ago exactly to reduce repetitive boilerplate.
Redux should never have been adopted in its current form. Its exactly the sort of thing that should be handled by a framework/tooling for you. Imagine if for every React component you had to write a custom parser/resolver/reconciler, all of which had 99% common code and just passed params around. That's what redux boils down to.