You're complaining about a couple different things. That particular reducer example is a bit terse, and could be made more readable. That said, yes, Redux (as

You're complaining about a couple different things. That particular reducer example is a bit terse, and could be made more readable. That said, yes, Redux (as a Flux Architecture derivative) does ask you to separate all your "write logic" from the rest of the application. This is explicitly part of the design. You may want to read Dan Abramov's article "You Might Not Need Redux", where he discusses the tradeoffs that Redux asks you to make, and the benefits you get as a result: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... . I'm also working on a blog post that will discuss the actual technical limitations Redux requires of you, vs how you are _intended_ to use Redux, vs how it's _possible_ to use Redux. The goal is to clarify where the various common aspects of Redux usage come from and why. I'm hoping to finish the post over the weekend and publish it early next week. If anyone's interested, keep an eye on my blog at http://blog.isquaredsoftware.com http://blog.isquaredsoftware.com .