In the blog post you linked to ([2]), you say:

>Ah, the dreaded switch statement. For some reason, this is one of the most disliked aspects of typical Redux code, and I have yet to figure out why.

The Redux docs take the position that switch statements are an implementation detail. The documentation author(s) provide an alternative approach, the action type to handler map, in the Reducing Boilerplate section. I think Redux advocates get a little bit impatient with the criticisms of Redux that amount to "I don't like switch statements". I share that point of view. Switch statements are an implementation detail and aren't worth arguing about when the Redux architecture does not depend on them. When I came up with redeuceur, I wanted to isolate independent operations. For me, breaking a larger function into smaller functions means less cognitive overhead. I would have used the createReducer idea from the docs but I needed support for arbitrary computed conditions rather than a simple action type map. So, it's not about getting rid of switch statements but more about making it easier for my average mind to keep track of things.

All of that being said, are you sure you're not being disingenuous when you say "I have yet to figure out why?" The strength of the animus against switch statements in Redux reducers might be a product of received wisdom or unreasonable bias. But the additional cognitive overhead of things like `break` vs. cascading `case`'s, and `default` is a reasonable basis for preferring `if` statements or something more declarative. As near as I can tell, the original Redux examples used switch statements because they were aesthetically pleasing to the author. There's nothing wrong with this. But it shouldn't be a surprise that people prefer a construct with less complex behavior, even if the complexity of a switch statement is manageable to someone with solid JavaScript experience.