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 :)