Hey Jared, you make some good observations. I don’t really address the benefits of action replay and time travel debugging. Surely these things would be more difficult with the architecture I’ve proposed. I guess I just feel that there is an unfortunate divide between redux-in-theory and redux-in-practice. And I fixate on reducers in the context of redux because I think this is the more interesting discussion. Local state management in react is trivial compared to global state management. From a conceptual standpoint redux is comparable to a CQRS architecture where actions represent events and in theory the state could be derived via event sourcing.

const currentState = events.reduce(reducer, initialState);

But again, in practice redux isn’t so straightforward and the UI state is rarely completely described by the redux store, which impedes the debugging capabilities that would normally come with such a solution. I think there’s also not enough discussion or emphasis regarding action names. Because in theory, yes, an action/reducer interface provides decoupling of user actions and state updates. But many times actions are named in a way that’s not actually descriptive of what the user did, but rather descriptive of the logic the reducers are about to perform. This implicitly couples the component to the business logic. On the whole, I question if a CQRS architecture is an overkill solution to UI state management.