Block Editor: All references to blocks should be accounted for in history

[youknowriad]

Right now, if we edit blocks, the history (undo/redo) is kept in the redux store using the withHistory higher-order reducer. But only the blocks substate is kept in the history while the block selection is not. Which means if we trigger undo/redo we can potentially end up with a state tree where the blockSelection points to a non-existing block. (For example a block that was removed by undoing a change).

We should explore whether moving the block selection reducer inside the withHistory Higher-order reducer could solve these issues and which side-effects it would have on the undo/redo behavior.

Related #12214

[aduth]

Am I correct in thinking that this could apply to any state which holds a reference to a block's clientId?

This would include:

• blockSelection
• blocksMode
• insertionPoint (?)
  • It holds rootClientId, which can become removed by Undo history
• reusableBlocks
  • Value is { clientId, title } pair
  • Ideally we'd opt for removing this state instead (Reusable Blocks: Reimplement reusable block as embedded editor #7119)
• blockListSettings

[youknowriad]

Am I correct in thinking that this could apply to any state which holds a reference to a block's clientId?

Yes, 👍

[aduth]

I think it's more accurate to consider this a bug. The issue has manifested itself in a few forms:

#15543 (comment)

click the "More" button and the editor crashes

I think the issue here is that wp.data.select('core/block-editor').getSelectedBlockClientIds() still returns the previously selected block, even though it has been deleted.

#12002

The expected result is that the focus was returned to the previous block.

[ellatrix]

@youknowriad Is this still relevant after #17824?

[youknowriad]

Maybe not, I was only aware of the selection. I think we can close and reopen specific issues if needed.