State Functions as Redux Models

When I first began learning about Redux, I instantaneously felt in love with it. I could define my front-end state mutation as pure functions that sounds great.

As I began working on a real world React/Redux app with 5 other developers, I found the complexity of code to be becoming kind of intimidating.

The only way to understand a functionality was to follow the actions using redux dev debugger and scan for handlers of the actions in codebase till you figured out how it all works together.

One of the reason was the way we were using redux-thunk. Lots of those issues were resolved once we moved to saga. But still there was a problem. State was suppose to be minimal source of truth. But then there were operations on the state, which represented the business logic. This logic was scattered throughout the codebase.

In my previous projects this problem was handled by creating right models and services with Angular. With react/redux there was no convention of using models. Everyone looked happy with scattering business logic throughout the codebase.

I knew we needed models but how to create them them with Redux ? The answer I got from people I asked was YOU CAN’T.

But why not ? Here is the top voted answer to the question on stackoverflow which tries to convince that redux way of doing things somehow does not need models.

I beg to differ. I think models are as necessary for a Redux based app as for any other system.

Models are the vocabulary of a system. Models bring sanity to the codebase. Without them a codebase looks like a series of insane distorted thoughts.

Problem is that all of us are used to models that encapsulate data along with functions (methods) and more than often mutate themselves.

So I came up with the idea of state functions. In short, these are all the kind of operations that you can perform on a state tree/subtree, from reducer or component.

State Functions

Just like models hold data and state, these objects hold the functions that can be applied to state.

Now reducer has just the core logic of mapping actions to business logic:

Not only reducer, but if components need to apply functional logic to read from state, the function should end up in state functions as well: