multiple:false support is not honored for shared and nested blocks

[oandregal]

Block types that have multiple: false in their supports array are intended to be included only once in a post. Take for example the More block.

This setting is not honored when those kind of blocks are converted to Shared or are nested.

How to reproduce

For shared

• Add a More block to your post.
• Open the block settings menu: no Duplicate option is shown.
• Convert the block to shared.

From this point on, the Duplicate option is shown in the block settings menu for the shared more block. The More block is eligible for adding from the inserter as well.

For nested

• Add the Columns (beta) block.
• Introduce as many More blocks as you want in any column.

The Duplicate option is not in the block settings menu, but you can add the More from the inserter and publish the post successfully.

[oandregal]

Tested this with the More button, and the BlockDuplicateButton's canDuplicate function returns false when it is a regular block and true when it's shared.

[oandregal]

Reason for that is that blockType.supports array doesn't include the multiple: false key when the More block is shared, so hasBlockSupport falls to default (which is true).

[oandregal]

The reason why the blockType.supports doesn't have the multiple: false prop is: when a block is converted to shared its type is changed to core/block. Any check on the type properties will be checking the ones defined for the core/block (the type of any shared block). Because supports is a type property, when the core/more block is transformed to core/block the multiple prop is no longer false, but the default (which is true).

[oandregal]

cc @noisysocks

[oandregal]

With my limited gutenknowledge I can only think of two approaches for shared blocks:

• convert some (or all) the block type properties into block instance properties
• do a "deep check" when a block is shared: if the block is shared, let's check the multiple prop in the original/referenced block type.

I lean towards the second option, but not sure about the scope (should we only do this for multiple?) and the potential side-effects of doing this.

[oandregal]

I've been looking at what happens with nested blocks. If a multiple:false block is added to the post, then it can't be added in any other context (within nested blocks, for example) because the inserter would show it disabled. If the block is first added in a nested context the inserter won't know and the block will be available to add.

This is what I've got atm: nested blocks use the InnerBlocks component, which ends up using the BlockTypesList component. BlockTypesList controls is responsible to render the list of blocks that can be inserted. The list of blocks is passed as the items prop by using this selector wp.data.select( 'core/editor' ).getInserterItems();. Items on that list have a isDisabled property which is used to determine its disability status.

[oandregal]

The getInserterItems calculates the isDisabled prop based on the top-level blocks. We can fix this by unfolding the top-level list into its components (shared to the referenced blocks, nested into children).

[oandregal]

#8075 has landed support for taking into account nested blocks to disable blocks that can't be added more than once.

We decided to put off SharedBlocks at the moment, see #8075 (comment)