blog/2025/event-sourcing/

[giscus[bot]]

blog/2025/event-sourcing/

Using event sourcing to implement undo/redo functionality in a React component.

https://ericjinks.com/blog/2025/event-sourcing/

[ecgan]

Good to see this from you, Eric! Thanks for documenting and sharing your learning experience! :)

I just want to share my thoughts and ideas with you here, so we can learn in public together.

Undo/Redo Functionality [...]
Time-Travel Debugging [...]

This is also how Redux is implemented, by using event sourcing (see https://redux.js.org/understanding/thinking-in-redux/motivation). That's how we can undo/redo a Redux action and do time-travel debugging using Redux DevTools.

historyIndex: number // Tracks where we are in the timeline

In your code example and article, you are using an events array and a historyIndex.

In my experience, it's more common to make use of two arrays or stacks, i.e. undoStack and redoStack:

• When we perform an action, the action is pushed into the undoStack (redoStack is cleared if there are items in it).
• When we undo an action, it is popped from the undoStack and pushed into the redoStack.
• When we redo an action, it is popped from the redoStack and pushed into the undoStack.

With this approach, the space complexity is the same. We don't need the historyIndex; the current state is always reconstructed from the whole undoStack.

Let me know what you think about this. :)

[Jinksi]

Hey @ecgan! Thanks for offering your thoughts on this 🙏

I love the approach, I'll have a play with implementing with an undoStack and redoStack, rather than historyIndex. It makes sense that it could simplify the logic quite a bit and would be easier to reason about.