Comparison
Event sourcingvsReducer
Event sourcing
you stop storing the current balance and instead store every deposit and withdrawal, deriving the balance by replaying them.
Persisting state as an ordered log of immutable events, with current state as a derived projection. You get a complete audit trail and the ability to rebuild any view by replaying history. What you give up is ad-hoc querying, cheap schema change, and the ability to ever delete anything easily — events are forever, including the ones with a bug in them.
Full entry →Reducer
you replaced five interacting `setState` calls with one function that takes the current state and an action.
A pure function from current state and a described action to the next state. Centralising transitions makes impossible combinations easy to rule out and makes every change loggable and replayable, which is why debugging tools are built around it. It is overkill for one boolean, and it is the right call the moment two pieces of state must change together or a transition depends on the current state.
Full entry →