Block Editor: Reusable blocks fetching causes "Unsaved Changes" prompt

[aduth]

Related: #14766

Describe the bug

Any action which triggers reusable blocks to become fetched will trigger the editor's mechanism to prompt the user when they leave the page.

This includes:

• Fetch as a result of autocompleters (selecting any paragraph block)
• Fetch as a result of toggling the Inserter
• Fetch as a result of a reusable block being present in the post's content

To reproduce

1. Navigate to Posts > Add New
2. Add a paragraph
3. Save the post
4. Reload the page
5. Select the paragraph block
6. Reload the page, or attempt to navigate away
7. Observe the prompt

Or:

1. Navigate to Posts > Add New
2. Click the inserter
3. Reload the page, or attempt to navigate away
4. Observe the prompt

Or:

1. Navigate to Posts > Add New
2. Insert a reusable block
3. Save the post
4. Reload the page
5. Reload the page, or attempt to navigate away
6. Observe the prompt

Expected behavior

A prompt should not be shown.

Additional context

There is a fair amount of debugging information available at:

• Merely selecting a block after load creates undo level #14766 (comment)
• Merely selecting a block after load creates undo level #14766 (comment)
• Merely selecting a block after load creates undo level #14766 (comment)

Specifically, the comment at #14766 (comment) describe that the reason this occurs is that when the block editor receives reusable blocks as a result of the fetch, it considers this a change in its own state, which surfaces up to the editor and is accounted for in considering to show the prompt upon leaving the page.

It is not easy to solve because:

• RECEIVE_BLOCKS may in-fact include dirtying changes, so it cannot be skipped for consideration in whether the BlockEditorProvider call the onInput or onChange props.
• The block editor module must receive blocks data for the reusable blocks, otherwise it cannot be shown in the editor (the implementation of the reusable block uses select( 'core/block-editor' ).getBlock).
• It can't be done as part of the normal "sync" operations between editor and block editor because technically these reusable blocks are not part of the blocks value (they are not necessarily in post content).

Ultimately this ties into the issues of #7119 and related explorations at #14367 and #14715 , where the block editor state is not responsible for holding data of the reusable blocks. These however are much larger tasks, and a more immediate fix should be explored.

I am currently considering a fix which would update the blocks autocompleter to trigger the reusable blocks fetch only when generating its own options. However, as noted above, this only accounts for one of three possible workflows to trigger reusable blocsk fetching.

cc @youknowriad in case you have thoughts.

[aduth]

A plan I'm considering for moving forward:

• Defer autocompleters reusable blocks fetching until after some input has been received. This would fix Merely selecting a block after load creates undo level #14766 and one of the cases described above.
  • I have a local branch I will be pushing up for this shortly. (Edit: See Editor: Trigger reusable blocks autocomplete when options generated #14915 for pull request)
• Implement a higher-order reducer withIgnoredChange which stores a boolean value assigned to true if the block-editor blocks state changes as a result of RECEIVE_BLOCKS. I see this being applied similar to the existing withPersistentBlockChange higher-order reducer and as part of the same condition of considering isSyncingIncomingValue in BlockEditorProvider.
  • (Edit: See Block Editor: Consider received blocks state change as ignored #14916 for pull request)
  • Note: This contradicts a point from my original comment "RECEIVE_BLOCKS may in-fact include dirtying changes". While granted, the proposed behavior aligns to what had existed prior to the block editor split of Try a generic block editor module #13088. At worst, it could be a temporary mechanic, though RECEIVE_BLOCKS in its current form serves only to aide in the reusable blocks flow.

Subsequently, we should follow-up with the more significant refactors of the reusable block to avoid needing to receive this blocks data into the block editor state, tracked at #7119 with related explorations at #14367 and #14715 ,