It’s entirely up to you how much abstraction you want to use in conjunction with Redux.
Mark Erikson

Sure, Redux is just a pattern for modifying your state, and it’s elegant in the sense that the way you do it is functional and pure and so on.

But that particular way of modifying state leads to writing a lot of functions that don’t really do anything. You switch on an action’s type, and return something.

Often it’s a combination of earlier state and whatever the action carried with it.

But what’s the benefit of doing that, compared to some other arrangement where you modify the same state in the same place, but more directly, without all the reducer boilerplate?

For example, I wrote my own little framework where I pass ‘messages’ that have a type and may carry data just like ‘actions’ in Redux.

I have a big old object that contains all the ‘State’ too. But I don’t have any reducers anywhere. Instead, some code receives a message that carries data and a string that points to where in the state object the data should go.

The state object is a tree-like structure of nested objects and values, of course, just like you might expect.

As far as I can tell, this approach has the same benefits as Redux, but without the boilerplate. State is modified in only one place, messages are handled sequentially so there are no race conditions etc, the way new data is merged is ‘immutable’ for the changed portion of the state structure, etc.

I’ve got a stream of messages and some code along the way that does stuff with them (or just passes them on without doing anything).

Anyhow, I don’t really know what to ramble about next, so I’ll just stop here.

Oh, one more thing. It’s seemed to me that ‘doing Redux’ is like _almost_ ‘doing streaming’. I think I’ve just taken things a bit further in terms of doing streaming. Streaming is good :)

Like what you read? Give Peter Lindstrom a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.