Show HN: redeuceur – A utility for creating terse Redux reducers
github.comHeh. Quoting my tweet from last December at https://twitter.com/acemarke/status/809427191306059776 :
> If I had a nickel for every lib I've seen that lets me "Write reducers with less boilerplate", I'd have... well, several dollars, anyway
Case in point, the "Reducers" page [0] in my Redux addons catalog lists dozens of reducer utility libs , and there's even more under the "Action/Reducer Generation" page [1]. (Yes, those two pages are cluttered and need to be reorganized, but I haven't had time yet. I'll also note that I did just add redeuceur to my list a couple days ago as well.)
So, good news is that if you want to abstract out the process of defining reducers and action creators, there's a gazillion libs out there to help you do that. As always, it's up you you to decide how much abstraction _you_ want to use in a Redux app [2].
[0] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
[2] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
Thanks for adding redeuceur to your list! I didn't realize there were so many reducer utilities but I'm not surprised. I like the way Redux leaves room for the user to play with the implementation.
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.
No, I genuinely don't understand why people hate switch statements :) Like I said in the post, a switch statement is a construct designed to implement if/else logic on the value of a single field, and since we usually want to do work based on the value of `action.type`, a switch statement is the obvious choice.
Now, I personally tend to use a function map utility in my own Redux code, but there's definitely nothing _wrong_ with switch statements, and I don't get the vehement complaints about them.