Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lack of support for multiplayer undo/redo (but Replicache is fundamentally multiplayer) #12

Closed
isaacHagoel opened this issue Jun 16, 2024 · 3 comments

Comments

@isaacHagoel
Copy link

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):

  1. Add two todo items from client A
  2. Delete the second todo on client B
  3. 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.

@aboodman
Copy link

aboodman commented Jun 17, 2024

We have an existing bug (confusing in the Replicache repo) for this here:

rocicorp/replicache#1008

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:

  1. Add two todo items from client A
  2. Delete the second todo on client B
  3. 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.

@aboodman
Copy link

Duplicate of #13

@aboodman aboodman marked this as a duplicate of #13 Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants