Reusable Blocks: Reimplement reusable block as embedded editor

[youknowriad]

At the moment, fetching reusable blocks also parses their content and insert them to the editor's block list state. This approach have some drawbacks:

• We need to maintain a cycle dependency between blocks and shared blocks
• Fetching shared blocks from the server retriggers the parsing which means if it's currently rendered, the block will unmount/remount.

I tried simplifying the state in #7080 but it fails at dealing with the nested blocks.

The idea of the PR is to avoid having to parse the reusable blocks (content property) when loading them, and when we insert a reusable block into the editor, don’t parse it and add the parsed blocks into the editor’s state because these parsed blocks are not part of the post content but just a property of the reusable block and is already present in the state in its serialized form.

So when we insert the reusable block, its edit method is responsible of parsing the content and updating it when the user saves the reusable block’s form.

But the problem happens when we have inner blocks because the way we render the InnerBlocks we assume these are present in state, we don’t pass the list of blocks to show explicitly to the BlockList as opposed to the BlockEdit (root) where we can just pass the attributes of the block to show.

The path forward is not clear:

• My “perfectionism” tells me we should refactor our component to avoid relying too much on state getBlock( uid ) and accepts blocks as props.
• But this is a lot of work and we lose a lot of flexibility in using selectors etc...
• We can also try to load another Gutenberg instance :man-shrugging: when clicking the “edit” button of a reusable block, but this obviously requires a lot of work to make Gutenberg reusable this way (which should benefit things like multiple Gutenberg instances in a page) and this also means we’d need to figure out where to show the inspector of this inner instance, should it be shown above the outer instance’s inspector.
• Or we should keep our current hack: (load the shared blocks inner blocks into state, but try to improve it in a way that we don’t remount the shared blocks when we update them/trigger another fetch)

related #5010 #5228

[aduth]

We can also try to load another Gutenberg instance :man-shrugging: when clicking the “edit” button of a reusable block, but this obviously requires a lot of work to make Gutenberg reusable this way (which should benefit things like multiple Gutenberg instances in a page) and this also means we’d need to figure out where to show the inspector of this inner instance, should it be shown above the outer instance’s inspector.

Something like this was also explored for nested blocks (i.e. idea of an embedded editor) and ultimately decided against with all the complications it proved to surface.

Related: #3745 (comment)

[aduth]

We need to maintain a cycle dependency between blocks and shared blocks

Is there really a dependency from blocks to shared blocks? As implemented, state.editor is meant to act as a canonical source of blocks, where shared blocks track only pointers to those blocks. It's admittedly become an issue because of change detection and because we consider since it's part of "editor" that those blocks exist in the post on the page (not always true). If we wanted the one canonical source, we could divide those in the editor to be treated as pointers as well, similar to shared blocks. I'm not sure how this works out to be able to detect when a change occurs, though.

Fetching shared blocks from the server retriggers the parsing which means if it's currently rendered, the block will unmount/remount.

Seems like there's a couple things we could be doing better here, not specific to state shape:

• Reusing a block UID when parsing a shared block which has already been received previously
• Not receiving (or not assigning as new state reference) a parsed shared block when it matches what's already known

[youknowriad]

Just thinking in terms of modules. I believe Shared blocks belong to core-data while the editor blocks is for the post content being edited. A block is not an entity in WordPress at the moment. Merging those would make sense if the post_content was exclusively built of persisted blocks.

[aduth]

Related effort: #7453

[noisysocks]

Noting for future reference that as part of this we should revert or revisit the workarounds added in #11787 and #11746.