undefined | Better HN

0 pointskarmajunkie9y ago0 comments

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

0 comments

4 comments · 2 top-level

weq9y ago· 1 in thread

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.

amk_9y ago

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.

weq9y ago· 1 in thread

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?

karmajunkieOP9y ago

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.

j / k navigate · click thread line to collapse