destructive updates to your universe, or actions with side effects (anything regarding io) might not be recovered by a simple state management. delete my account, charge my credit card, add a friend, delete a friend...
But that is precisely how undo is currently implemented most of the time. Its a series of actions where you know how to undo the side-effects, or you know it was a destructive update and you just skip the undo of that step.
Where I have issues with that is it usually feels like an afterthought rather than a first-class feature.
If you instead model your application after an event log then your current state is just a fold over these events. You have the same list of actions you previously had to manage undo, but now its positioned at the very center of the architecture.
And then you start seeing emergent features of that design:
- you can time travel the UI's state, which is probably the best debugging tool you can have for UIs.
- you can replay the event log over fixed application code, which greatly decrease iteration times.
- it moves logic outside of the UI components, making the app easier to unit test.
- you're storing a sequence of intents rather than results; its effectively free to audit such a design, its convenient to report the last X actions performed with a bug report and more precise than asking the user what they were doing.
The list goes on and on. I believe most of the complexity in applications is generated from the fact there is very little synergy between the different features of these applications. If everything requires a different abstraction and set of indirections, then you're just accreting complexity over time.
If you have a design where features can emerge from it, its usually a safe-bet to say you're on to something :)