Hacker News Reader

Comment by bradmwalker | Hacker News Reader

Redux uses Event Sourcing. ES's trade-offs apply.

Its evented, not normally event-sourced. I don't know of many production uses of redux that also store the events for replay.

Redux in its essensce encourages half assed event sourcing.

Why do i need to memoise my state to stop the react render loop from happening? Isnt my event the source of truth? Its much more then a DTO.

Once your application becomes "event centric" instead of "state centric" you start to actually break free of the procedural paradgim and really become functional reactive.

Redux to me is DDD and ES for non-programmers. My domain logic is the gatekeeper to my state, and as such, should be coupled together. I dont combine my aggregates, just the same way i dont combineReducers. Code smell much.

An app really becomes an app instead of a view layer for a CRUD API once you start adding in business logic, permissions, unstable networks, etc. I'd love to see a Redux example app that handles those things as cleanly as it handles simple cases.

Addtionally;

Why apply your event to the state, then somehow sync your state with the server.

Wouldnt it be simplier just to sync your events?

Yeah, its simpler, I just don't see many applications doing it. Additionally, not all events need to be synced, some need to be enriched before being synced... by the time you've done all that, you're almost back to syncing state. Which is probably why we don't see many apps doing this with redux.

Redux is much more closely aligned with CQRS principles than ES.

Reply on news.ycombinator.com