You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I read the code and noticed it is implemented as a single client undo/redo queue (it doesn't subscribe to the Replicache store) even though Replicache is a multiplayer system. This can lead to all sorts of unexpected behaviours:
Simple example (that I reproduced on TodoMVC):
Add two todo items from client A
Delete the second todo on client B
Click undo on client A, nothing happens (from the user perspective - bug, if they click again the first item is removed)
It can get much more complicated than that when a series of conflicting changes are done on two (or more) clients.
If the undoing client is offline things get even more gnarly.
I understand this is not an easy problem in multiplayer system but even if this lib doesn't solve it I think it needs to create an affordance that would allow the consuming app to solve it.
If the lib does attempt to solve this for everyone, one approach is to adopt the solution implemented by Figma (see here):
Undo history has a natural definition for single-player mode, but undo in a multiplayer environment is inherently confusing. If other people have edited the same objects that you edited and then undo, what should happen? Should your earlier edits be applied over their later edits? What about redo?
We had a lot of trouble until we settled on a principle to help guide us: if you undo a lot, copy something, and redo back to the present (a common operation), the document should not change. This may seem obvious but the single-player implementation of redo means “put back what I did” which may end up overwriting what other people did next if you’re not careful. This is why in Figma an undo operation modifies redo history at the time of the undo, and likewise a redo operation modifies undo history at the time of the redo.
Happy to brainstorm and/or contribute a PR if needed.
Thanks.
The text was updated successfully, but these errors were encountered:
I've created a new tracking bug here at #13 to reference it.
I'm familiar with the articles you mention, but I don't believe they help with the case you describe:
Add two todo items from client A
Delete the second todo on client B
Click undo on client A, nothing happens (from the user perspective - bug, if they click again the first item is removed)
In the Figma implementation, this will also do nothing at step 3. Here's an example:
CleanShot.2024-06-17.at.14.09.39.mp4
The same thing happens in Notion. And I think it makes sense – if I press paste twice, then cmd+z twice, I expect to go back to the state before I copied anything. This unfortunately means the first cmd+z appears to do nothing, but that is less weird than the number of actions not matching up.
Our implementation does have some problems, you can see the Notion doc for details, and for the beginning of an idea how to fix. Would love any contributions if you want to work on that.
I read the code and noticed it is implemented as a single client undo/redo queue (it doesn't subscribe to the Replicache store) even though Replicache is a multiplayer system. This can lead to all sorts of unexpected behaviours:
Simple example (that I reproduced on TodoMVC):
It can get much more complicated than that when a series of conflicting changes are done on two (or more) clients.
If the undoing client is offline things get even more gnarly.
I understand this is not an easy problem in multiplayer system but even if this lib doesn't solve it I think it needs to create an affordance that would allow the consuming app to solve it.
If the lib does attempt to solve this for everyone, one approach is to adopt the solution implemented by Figma (see here):
Happy to brainstorm and/or contribute a PR if needed.
Thanks.
The text was updated successfully, but these errors were encountered: