Gutenberg-mobile: Undo and redo

[koke]

Users should be able to undo their changes and redo them. We'll have two buttons in the toolbar for this.

Some requirements:

• Undo/redo should restore both content and cursor/scroll position.
• We need to define how undo actions are grouped (i.e. we don't want to undo every character typed). Look into what Gutenberg does and what's the typical behavior in each platform, then make a decision.

[koke]

@mzorz do you mind looking at this one and doing the breakdown and estimation by Wednesday?

[mzorz]

REDO/UNDO notes

Observing how undo/redo history works by experimenting on Gutenberg web:

• entering text in a paragraph is a full action, and starts recording as a full steps after a few seconds - so instead of each keystroke, it just has a timer that gets reset on each keystroke and then after a few seconds, maybe 5 or so it pushes the state into the Undo History.
• if you type something but don't wait for the timer to go off and rapidly hit UNDO, then the current state of things is compared and gets another UNDO stepping into the History queue. So: each time the UNDO/REDO is tapped, the current state is compared.
• we could reutilize the mechanism we have for Aztec, but that works only intra-aztec. We will have to piggy back on it (make an external interface) or modify code in there to not record every keystroke (at the Aztec level) but rather implement the timer there.
• each of the block-level actions are recorded as steps. i.e.: insert / convert block
• BLOCK states: each block's own state change makes up for a step in change History. For example, take an Image block.
  
  
  
  • Adding a block is an undo history step
  
  
  • choosing an image and uploading it is another undoable history step
  
  
  • adding a caption is an other undoable history step
    
    etc.
  
  
• interestingly, typing a list has no granular steps other than the timer (i.e. each bullet does not make itself an undo step point but rather the full thing you can write with the timer not being reset is)
• cursor positioning: while it's being set as a requirement, it doesn't look like it matters for Gutenberg web. I do agree we should focus on the block where the last step happened, or if the last step was introducing a new block (and now it's getting removed) then make a decision on which block should get the focus (probably the one above the now-removed block?)

From the code perspective, idea here is see if we can reuse the same code as Gutenberg has for undo/redo logic as much as possible, we'd need to:

• [ ] provide / make adjustments to support state.editor.past in our own redux store (see how that plays)
• [ ] see if withHistory object can be made accessible from gutenberg mobile repo or adapt make our version (like we have our own rollout of the block list in block-manager.js
• [ ] make adjustments to Aztec and interface layers to propagate Undo/Redo to the upper level (Aztec wrapper -> block -> toolbar).
• [ ] connect buttons to the toolbar
• [ ] cursor positioning

This looks like a full sprint worth of work to me. cc @koke

[koke]

Thanks for the thorough testing @mzorz I'm sure that'll be very useful when we start working on it.

[hypest]

Looping in @Tug here as I think this feature will touch the GB data layer a lot and, it makes sense to work with @mzorz to figure out how to reuse the GB code.