Event sourcing in frontend
Slap yourself if
You think event sourcing is just Redux with better naming or only belongs on the backend.
Why this exists
Event sourcing in frontend exists because UI state changes are temporal, not static. When correctness, replayability, or auditability matter, snapshot-based state hides the very information you need to reason about bugs and user behavior.
Mental model
State is a projection. Events are the source of truth. If you only store the latest state, you’ve already thrown away the explanation for how you got there.
- User interactions and system actions are recorded as immutable events.
- Current UI state is derived by replaying those events.
- Different projections can exist for the same event stream.
- Bugs are reproduced by replaying history, not guessing.
- Treating events as verbose actions without semantics.
- Storing derived state alongside events and letting them diverge.
- Ignoring event ordering and idempotency.
- Assuming event sourcing removes the need for state modeling.
Event sourcing in frontend means modeling user interactions and system changes as an immutable event log, deriving UI state from those events instead of mutating state directly.
- State updates without corresponding events
- Events that mirror reducers one-to-one
- No strategy for replay or versioning
- Assuming time-travel debugging equals event sourcing
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.