History: Batch title and text editor edit undo history

[aduth]

Closes #4057
Partially addresses #2932

This pull request seeks to improve the behavior of editing the title and text editor to limit the number of undo levels created when typing within the field. Prior to these changes, an undo level was created for each character pressed in the field. With these changes, the withHistory higher-order reducer has been enhanced to support batching, such that multiple sequential edits will be grouped into a single history level.

Testing instructions:

Repeat Steps to Reproduce from #2932, verifying both for the text mode and title field that undoing applies to all edits made while the field was changed.

[jorgefilipecosta]

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.

[aduth]

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?

[aduth]

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.