Editing post in Text Mode causes shared blocks to go away

[noisysocks]

Issue Overview

If you edit a post using Text Mode, any shared blocks will appear as though they have been deleted when you return to Visual Mode.

Steps to Reproduce (for bugs)

1. Create a new post
2. Create or insert a Shared Block
3. Switch to Text Mode
4. Make an edit, e.g. add a line of text
5. Return to Visual Mode

Expected Behavior

The Shared Block should render properly in the visual editor.

Current Behavior

The Shared Block appears as though it has been deleted.

Possible Solution

This is because RESET_BLOCKS is dispatched when PostTextEditor is blurred. This has the unintended side effect of deleting the block that the Shared Block is referencing.

One solution is to change RESET_BLOCKS so that it doesn't delete any blocks in blocksByUid that are referenced by orderedBlocks or reusableBlocks.

cc. @aduth

Screenshots / Video

Related Issues and/or PRs

#5228 introduced this bug. I discovered this while debugging #2978 which is vaguely related.

[noisysocks]

#7453 (or any similar refactor of how we implement shared blocks) will likely fix this.

[slimmilkduds]

I’ve checked related the tickets related to this. Is it right to assume that this problem probably wont be resolved until 5.0 or later?

For me this is an incredibly annoying issue since my only plan atm for templating involves using e.g. an 3rd party section block or a hacky 1 column column block to store a bunch of blocks as a reusable block (and to convert that to a regular block after importing the ”template”)

I know there’s a way to make a specific template load for CPTs but we need to be able to have multiple templates availiable for each CPT.

Sorry, rant over.

[dkieffer]

@slimmilkduds my current workaround until this is fixed is creating custom html reusable blocks.

[slimmilkduds]

@dkieffer The custom html reusable block, how does that work?

[dkieffer]

@slimmilkduds add a custom html block, make some sections or divs or whatever, then convert it to a reusable block.

[slimmilkduds]

Now since
#7453 got pushed to phase 2, is there any chance of some stop gap solution to this or will 5.0 actually ship with this bug?

[noisysocks]

Yes we will need to fix this. Note that it's up to the release lead whether or not #7453 will be punted. Right now, it's still in the 5.0 milestone.

For me this is an incredibly annoying issue since my only plan atm for templating involves using e.g. an 3rd party section block or a hacky 1 column column block to store a bunch of blocks as a reusable block (and to convert that to a regular block after importing the ”template”)

If I'm understanding you correctly, #9732 which was shipped in Gutenberg 3.9 should let you turn multiple blocks into a single reusable block.

[slimmilkduds]

Yes we will need to fix this. Note that it's up to the release lead whether or not #7453 will be punted. Right now, it's still in the 5.0 milestone.

For me this is an incredibly annoying issue since my only plan atm for templating involves using e.g. an 3rd party section block or a hacky 1 column column block to store a bunch of blocks as a reusable block (and to convert that to a regular block after importing the ”template”)

If I'm understanding you correctly, #9732 which was shipped in Gutenberg 3.9 should let you turn multiple blocks into a single reusable block.

Yeah, that was written before 3.9. The problem is that with the reusable templates released in 3.9 this bug only becomes more apparent. Creating a reusable block from multiple blocks is a 100 times smoother than what I was planning to do pre 3.9. I imagine loads of users will be pretty disapointed to have such an awesome feature rendered unusable if you want the reusable template to contain a column or any other block with nested support.

[slimmilkduds]

Just to be clear, it’s another issue I’m referring to (
#9278) that you mentioned likely had the same root cause as the one described in this ticket

[noisysocks]

Thanks for the clarification @slimmilkduds! I'll look into getting a quicker albeit less ideal fix in for these two bugs 🙂

[slimmilkduds]

That sounds great! ☺️

[noisysocks]

This is because RESET_BLOCKS is dispatched when PostTextEditor is blurred. This has the unintended side effect of deleting the block that the Shared Block is referencing.

One solution is to change RESET_BLOCKS so that it doesn't delete any blocks in blocksByUid that are referenced by orderedBlocks or reusableBlocks.

This still holds true and is a little tricky to address. Some ideas:

1. Change the shape of state so that blocksByClientId and orderedBlocks are removed in lieu of a blocks object with a byClientId and order subtrees. Then, RESET_BLOCKS could ignore blocks that are present in the .order subtree. @aduth also did this as part of Editor: Reshape editor state for optimized and accurate dirtiness detection #10844.
2. Mark reusable blocks in blocksByClientId with a flag e.g. isReusable: true. Then, RESET_BLOCKS could ignore blocks that have the isReusable flag set. getBlock could strip this flag out so that there isn't any extra API which we have to maintain.