I think only some blocks would want to implement this (container being the main candidate).

The question is ... how should it be declared? Perhaps as a block setting? Would it live under supports? e.g.

supports: { appender: 'button' }

or

supports: { buttonAppender: true }

The InnerBlocks component has a bunch of props to configure it right now, so I think it's fine to keep using a prop for consistency.

I've played around with an improved column appender as well for the CoBlocks Row/Column blocks. A bit different UI to look at. 💪

@youknowriad @talldan To confirm we're saying

1. This should be opt in via the parent Block which uses InnerBlocks
2. Opt-in should be via a prop passed to InnerBlocks (as opposed to a new API)

Please see my commits 0e1dd78 and 58c60f0 which address this by making it opt in via a prop on InnerBlocks (documented).

Demo - note that Columns is opting in, whereas Media + Text has not opted in. Both Blocks use InnerBlocks:

Question: is the "prop drilling" ok here? Is there a better way?

@richtabor This does indeed look very similar. Are there any enhancements/learnings you'd like to share to benefit this PR? Much appreciated. @melchoyce did the design on this one I believe.

@richtabor This does indeed look very similar. Are there any enhancements/learnings you'd like to share to benefit this PR? Much appreciated.

The most important part here is ensuring that folks understand that they can click the appender to add a block.

Also, I've considered keeping the appender at the bottom of the column block, so that users can still easily add blocks after an initial implementation. I was finding that folks were unsure how to add blocks again, once the appender placeholder had been removed (as blocks were added).

@richtabor Thanks for your input.

The most important part here is ensuring that folks understand that they can click the appender to add a block.

I'm hopefull that the wording "Add a Block" should suffice (not intending to be sarcastic here - just an observation). I like the background colour on your version as this enhances the perceiability yet further, but I'll defer to @melchoyce on this one.

I've considered keeping the appender at the bottom of the column block

It's a nice idea and one I think could/should be explored in a follow on PR if that's ok with you?

Could "Add Block" be sufficient, as oppposed to "Add a block"? Short and sweet, and it's always good to consider translations that nearly always balloon best intentions.

We use rgba(139,139,150,.1) for placeholders; let's try that out here in a couple contexts to see how it works.

Oh, while I'm thinking about it — is there any way to figure out if the appender is on a dark background, and if so, flip the colors over to white for contrast?

I think we have an SCSS variable for that opacity color, and be sure to test it in dark editor styles!

I've added a few extra commits to address the feedback.

Mostly, I haven't made any major changes, but one thing I'd like to do is move the HideWhenChildBlocks component to a separate PR, since it's one of the few remaining points of discussion, and I don't believe it's needed at this point.

I've removed it from this PR and have a separate branch that still has it.

Great! Other PRs incoming:

• Adding this to the group block. (Use button block appender on group block #14943)
• A PR revisiting the HideWhenChildBlocks component. (no related PR yet, still some ongoing iteration on the renderProp, see Try using createElement for renderAppender render prop #15259)

@talldan Whoa I barely recognised the PR! Thanks for all your work to get this merged 👍

Could you link to the PRs referenced above?

Can't found this function in 5.5. confused...

Hey @SchneiderSam - it's being rolled out to blocks on a case by case basis. At the moment it's only been added to the group block.

It was implemented for the group block on a separate PR, but unfortunately missed 5.5 and 5.6. It should be in 5.7, which is due to be released on the 15th May:
#14943

I used the renderAppender prop on <InnerBlocks> to render a button that says Add list item for a custom list block. Previously had to click on the appender button and then select the block from a selection of 1 block, so this prop is great.

How ever the button doesn't work when clicking it while the parent block is inactive, it just activates the block. End up needing to click twice most of the time.

Looking at why the normal appender works with one click, but my custom one doesn't, the difference seems to be <IgnoreNestedEvents>:

https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/components/block-list-appender/index.js#L30-L52

I don't think it's exposed, so I copied the <IgnoreNestedEvents> to my library and wrapped my appender button in it and then it works.

Perhaps expose the <IgnoreNestedEvents> for general use or add a prop to use it?

My code:

(hook)

import IgnoreNestedEvents from '../IgnoreNestedEvents';

export default function useAppender(element, blockName, clientId) {
	const append = useCallback(() => {
		const block = wp.blocks.createBlock(blockName);
		const index = wp.data.select('core/editor').getBlocksByClientId(clientId)[0].innerBlocks.length;
		wp.data.dispatch('core/editor').insertBlock(block, index, clientId);
	}, [blockName, clientId]);

	return () => {
		return (
			<IgnoreNestedEvents childHandledEvents={['onFocus', 'onClick', 'onKeyDown']}>
				<element.type {...element.props} onClick={append} />
			</IgnoreNestedEvents>
		);
	};
};

(used in block edit)

const Edit = ({clientId}) => {
	...
	const appender = useAppender(
		<button>Add list item</button>,
		'custom/listitem',
		clientId
	);
	...
	return (
		...
		<wp.blockEditor.InnerBlocks
			allowedBlocks={['custom/listitem']}
			templateInsertUpdatesSelection={false}
			renderAppender={appender}
		/>
		...
	);
};

Hey @websevendev,

I'm not entirely sure why IgnoreNestedEvents is not exposed. It might be that there are some considerations around its use, so the idea is not to promote it being used externally.

I think there might be two approaches to solve your problem:

1. Expose IgnoreNestedEvents as you suggest. It would need some documentation.
2. Add some improvements to InnerBlocks.ButtonBlockAppender so that you can pass in your own button text. You'd then be able to use that component instead of having to build your own button appender.

Is this an improvement that you might be willing to contribute? A good first step would be to make an issue, but a PR could also be an option. Let me know what you think.

The benefits of <IgnoreNestedEvents> seem to be diminished now by #15537 since you can't directly click the button most of the time anyway, so it remains to be seen whether there's any reason to do anything.

Add some improvements to InnerBlocks.ButtonBlockAppender so that you can pass in your own button text. You'd then be able to use that component instead of having to build your own button appender.

My previous code example was a bit stripped down, it's not just a <button>, it's got an icon, matches the theme and can handle itself on a dark background, so for me just being able to control the text wouldn't be enough which is why renderAppender prop is great and InnerBlocks.ButtonBlockAppender should probably remain as simple as possible given that there's a powerful alternative.

There's possibilities to add multiple buttons, maybe duplicate last list item button, etc. So just exposing the IgnoreNestedEvents is probably the best or making it available with a prop

<wp.blockEditor.InnerBlocks
	renderAppender={appender}
	appenderIgnoreNestedEvents={true}
/>

or perhaps enabled by default and a prop to disable it? I wonder what the use cases would be for not using it.