Custom undo/redo possible for block?

[amyriounis]

Is there any way of opting-out of the default undo/redo behavior and handling block history explicitly in my block?

I've tried my luck with this:

withDispatch( ( dispatch ) => {
		const {
			createUndoLevel,
			redo,
			undo,
		} = dispatch( 'core/editor' );
		return {
			onCreateUndoLevel: createUndoLevel,
			onRedo: redo,
			onUndo: undo,
		};
	} )

but it doesn't seem to have any effect on how undo/redo affects my block. Maybe I'm not using it the right way. Could you please provide an example of how a block can handle it's own history?

Why I need this
My block needs to be aware of it's innerBlocks block types and performs checks on them to assure it. If something is out of place (a block of another type is inside it) it creates a new block of the correct type and moves the stray block* inside it. You can see how a normal undo/redo operation would be problematic in this context, as the past/future result of an undo/redo operation consists of more than one actions.

I think that essentially what I need to do is to define when undo levels are being created for my block. Although, I cannot seem to find a way to prevent automatic in-between undo levels from being created, which would eventually lead to corrupt block state.

*stray block = block of a type that shouldn't be a direct child of the parent block (think of a row - column implementation)

[jorgefilipecosta]

There is some work in progress as part of the phase 2 scope to improve undo behaviors maybe the new solution is useful here. cc: @aduth, @mcsf

[mcsf]

At the moment, it's looking like the next improvements to Undo/Redo (see long soul-searching in #8119) will preserve the model of tracking the editor's history as a whole, as opposed to a scenario of per-block history management. That said, if we do end up implementing the concept of sagas or history amends to a given block, that could be useful to the present intended use case.

However, your use case is currently not supported, @amyriounis.

[amyriounis]

@mcsf Thanks for the response, it properly addresses my initial question, and so as far as I am concerned, this issue can be closed. If you think keeping it open might be of use to someone else or serve as a reminder towards another direction regarding editor's history model further implementation, no problem either.