I am wrestling with this too - my thinking is that if we want to hook into the platform UndoManager there isn't a way around having to pass it a store since it needs to send an action back to an object, although it doesn't seem that nice to pass stores as parameters to actions...
I was hoping there was some higher order way of solving this - I am thinking there might be a way to write a pullback function like the forEach functions which will pass the store as a parameter for you like this.
counterReducer.passingStore(
state: \CounterListState.counters,
action: /CounterListAction.counter(store:action:),
environment: { _ in CounterEnvironment() }
)
Conceptually I think an action is just a redo, and undo is the opposite of that. So the undo stack is just a FIFO array of Effects. I wonder if we could write a class to wrap the undo manager which maintains its own list of effects and registered uniform target / selector?
It would be great if the Composable Architecture authors could weigh in here 