mrpmorris
commented
2 years ago I don't think automated undo is a good pattern.
The state you have in your client is what you believe to be true, according to the last info you received from the server. The problem with automatic undo is that it is a lie. It pretends the server state is different to that which you know it to be.
For example 1: Get a customer 2: Edit the customer name from Bob to John 3: Save the customer 4: Effect sends an HTTP request to update the customer 5: User clicks Undo
All this does is lie to the user that their change was undone. The user is left with the impression the damage they've done has been undone, when in fact it hasn't.
The correct way to implement undo functionality is to add a step 4B 4B: A SaveCustomerAction changing name back from John to Bob is pushed onto a stack.
The user can then do a simple Undo (which executes the reversing action at the top of the stack) or even select an action in the stack to execute.
Always play forwards, never go back.
If this is an in-memory only thing then it is okay, but you should make that absolutely clear that this is all it does.
I think the standard naming convention for other people's libraries is to name it "Fluxor.Extensons.Undo"
Hello, In Redux there is a package redux-undo which is easy for implementing undo/redo functionality. I needed something similar so I created similar functionality for Fluxor. Because it is generic maybe it is nice if I share it. It does not have any dependencies (except Fluxor off course). In my opinion I can do 2 things:
1) Make a pull request here with the functionality 2) Create a separate nuget package which I will maintain
If nr 1: Where do you want me to add it? if nr 2: Can I call it Fluxor.Undo or is Fluxor a reserved prefix? And when done, can you take a look at it and if you find it OK, link from your readme to the package?