List View / Off Canvas appender doesn't respect allowedBlocks when InnerBlocks isn't rendered

[talldan]

Describe the bug
Related #18100

This is a very niche issue and hard to explain, but one that might become apparent if we start using the block navigator more.

#18100 introduces a block appender in the navigator:

The issue experienced is that If a user accesses the navigator before InnerBlocks had rendered and then clicked an appender, the user could insert any type of inner block, despite there being allowedBlocks defined on InnerBlocks.

The issue was that the InnerBlocks component had some conditional rendering:

gutenberg/packages/block-library/src/navigation-menu-item/edit.js

Lines 196 to 201 in 3d6392d

	{ ( isSelected || isParentOfSelectedBlock ) &&
	<InnerBlocks
	allowedBlocks={ [ 'core/navigation-menu-item' ] }
	renderAppender={ hasDescendants ? InnerBlocks.ButtonBlockAppender : false }
	/>
	}

If for any reason the component wasn't rendered before accessing the navigator, allowedBlocks wouldn't work as registration of those allowed blocks is dependent on the component mounting.

Questionable whether this is considered a flaw or a bug in the block implementation, but it's something that can't really be policed for third party blocks and could cause some very unusual issues for users creating posts.

[jorgefilipecosta]

Hi @talldan, maybe the way to address the issue is that we should never render an insert for an InnerBlocks are while the InnerBlock settings are not yet known? E.g: the inserter for the navigation should not render while InnerBlocks itself is not being rendered.

[draganescu]

Just posting for history sake: in the navigation block this was "solved" by not rendering innerBlocks conditionally anymore. This issue is about fixing the behaviour of the appender in the navigator and also an open question if conditionally rendering InnerBlocks is a good idea in the 1st place.

[talldan]

Closing this fairly old issue. While it's still could be a problem, it seems fairly stale and there haven't been any further mentions of it.

Some day, allowing allowedBlocks, template, templateLock to be specified in the block metadata would solve the problem.