Slate: Selections and operations should be batched differently in undo/redo

[Slapbox]

I believe what Google Drive is doing is the standard undo/redo behavior in all rich text editors I've used. Slate is a bit more granular and as a result it takes twice as many undos to actually undo things in some circumstances.

Google Drive

• Example
• Total Undos: 4

Slate

• Example (Sorry for slowness - had to go slow due to low framerate)
• Total Undos: 7

[Slapbox]

Another example of a problem this creates is the loss of the redo history in a circumstance like this:
Slate handling
Google Docs handling

The Google Docs behavior seems to be the default behavior for all text inputs I can find.

[Slapbox]

@ianstormtaylor thoughts on this?

[ianstormtaylor]

I haven't looked at it recently, nope. It's something that I'd like, but I didn't dig in enough to figure out what a good abstraction for it would be.

[Slapbox]

Can you point me towards where undos/redos are being created for selection changes? I found some history related files, but not that bit in particular.

[ianstormtaylor]

@Slapbox the on-history changes file should be it. And then in the on-select changes file there's a snapshotSelection change method that's kind of a hack that just creates an extra save boundary in the history for going backward—ideally this hack wouldn't exist probably.

[Slapbox]

Thanks for the tip! I'll take another look at the on-history file and at on-select and see what I can come up with.

[ericedem]

The way we are currently managing undo / redo is by tracking change operations, and then performing their inverse.

I am wondering if a better approach might be to just save the exact value whenever the document changes due to a user action and restore it as it was before. That way we would always know exactly what the selection should be with a given undo, since it is contained in the value.

This should also be memory efficient, since Immutable.js reuses unchanged structures, and already only tracks differences.

What do you guys think?

[ianstormtaylor]

@ericedem we do it the current way because by re-applying the inverted operations it automatically works with collaborative editing environments. The way you describe is totally possible, and could be a good candidate for a plugin I think.

[Slapbox]

@ianstormtaylor I'm really excited about the editor controller concept, but I'm wondering how it relates to this ticket. I'm probably overlooking some pretty basic implication of this new way of doing things. Can you provide any further thoughts on this?

[ianstormtaylor]

It's related in that it gets us a step closer, but doesn't unlock anything by itself.

[Slapbox]

Thanks for the clarification.

[ianstormtaylor]

I believe that this may be fixed by https://github.com/ianstormtaylor/slate/pull/3093, which has changed a lot of the logic in Slate and slate-react especially. I'm going to close this out, but as always, feel free to open a new issue if it persists for you. Thanks for understanding.