Rethinking Redux (and reducing its boilerplate)

Sunrise in the Sea by Emilio Srougo

tl;dr: redux-create-module

Suppose you want to create a new module in your react-redux app. You know the drill. Create the action type constants, make and the action creators, and handle the types in the reducer. You may have noticed that the process looks the same almost every time. We, as developers, know that this kind of things could, and should be abstracted and automated.

So, first let’s think what’s the best solution for Developer Experience. Or, since we are the Developers, let’s just Rethink Redux.

Well, if we are only interested in mapping actions to states, my first thought is to make a Map. Or a regular object, for that matter.

But we don’t want to create the reducer. We only want to think about the Map. Let’s make a function that takes a Map and returns a reducer

So simple! Or, too simple! Because we have a problem here. Action creators were invented for a reason, and that’s because some actions need to have a payload to be handled… Or is it? No! of course, there is another reason and that’s because it’s unsafe and ineffective to pass strings to the reducer. What if we make a typo on it?! So let’s get more serious now.

We still don’t want to create the action creators manually, and, why should we? Think about it, createReducer already has all the information it needs to make them. It can get the types of our actions from the keys of the Map. So, let's make it return both, a reducer and the action creators, and name it createModule

Neat!

Of course, we still have some todos. like namespacing our actions to avoid conflicts, and allowing a reducer to handle an action from another module. But we won’t get into that in this post.

Instead, I’ll refer you to the source of the little module I made.

Thanks for reading!

If you liked this post, please follow me at https://twitter.com/emilio_srg