I did some tests and things look in a good direction, I really like how the problem was handled on the withHistory using the batching mechanism. Nice work 👍

I compared our undo to some text editors and it looks like right now we may undo too much. E.g if the user writes a very big paragraph we may undo all of it. Most editors use space and "." to mark the end of an undo level. It looks like we can easily do this by checking the last char of title/content and not use batching if it is a space or point.

Another thing may also make sense is to not apply batching if the action type is different from the last one. But It may be technically hard to do as it would evolve some way of accessing the last action type.

I compared our undo to some text editors and it looks like right now we may undo too much. E.g if the user writes a very big paragraph we may undo all of it. Most editors use space and "." to mark the end of an undo level. It looks like we can easily do this by checking the last char of title/content and not use batching if it is a space or point.

Currently the undo within the paragraph block is managed by TinyMCE. This would change with #2758, and Undo is a major concern for making progress there.

Another thing may also make sense is to not apply batching if the action type is different from the last one. But It may be technically hard to do as it would evolve some way of accessing the last action type.

It's an interesting point to raise. I think if there were an action which is dispatched while batching is in progress that would cause a change to state.editor, then it would discontinue batching. I think this might be the best case scenario?

Closing in favor of #4956.

We will still need to incorporate title / editor batching after those changes are merged, but it sets a better framework for doing so.