Dan Abramov answered the question of “what benefits does Redux give me?”
Mark Erikson

Ohh, you’re “acemarke”, right?

>> Later, developers frown at the indirection Redux introduced to their code. “Why do I have to touch three files to get a simple feature working?” Why indeed!

Why indeed, when I can just not use Redux and avoid that problem! :)

No but seriously. The post starts off by acknowledging the main problem with Redux. It’s a real problem and it’s not going away.

> time travel debugging,

It’s easy to get at least most of that with any streaming-like solution, including mine.

>easy state persistence

What’s this supposed to mean?

> easier undo/redo

The streaming thing again.

> straightforward syncing approaches

No idea what this means either, or how it would be specific to Redux.

> differences between a “lens/cursor” approach and Redux’s “reducers” approach is that reducers are just functions, and are therefore composable to build up specialized behavior

So is the “lens” function, or whatever. It’s a central place where state gets modified.

It just doesn’t need to run dozens of other functions to get the job done.

I don’t want to compose reducers. I just want to put some data in a specific place. It’s way easier to accomplish that by doing *that*, instead of having dozens of boilerplate functions called for the same purpose.

> That could be something simple like delegating responsibilities for a given slice of state to a specific function (`combineReducers`), or wrapping an existing reducer in other reducers to enable capabilities like undo/redo or resets.

I don’t need to combine reducers because I have none. Again, I just put some data where I want it.

But I’m curious about the undo thing. You probably have a link handy :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.