Implement image block placeholder

[aduth]

Closes #454

This pull request seeks to implement the placeholder image block. It is currently not functional; there are no behaviors to drop or insert an image from the media library.

Open questions:

• I'm thinking it probably doesn't make much sense for the alignment controls to be shown while the placeholder is shown. This exposes a need to be able to dynamically generate a block's controls depending on its current attributes. We could do this by allowing the block implementer to optionally specify controls as a function. Or, depending on how far we want to take the Slot & Fill idea (Try Slot & Fill pattern for rendering Editable formatting controls #507), assume that a block must render its own controls via <Fill>, meaning they'd have full control over the rendering from the edit function.

Testing instructions:

Verify that after inserting a new image block, a new block is added with a placeholder appearance.

[ellatrix]

I'm thinking it probably doesn't make much sense for the alignment controls to be shown while the placeholder is shown.

I think this could still be useful for laying out a page, and adding the images afterwards.

[ellatrix]

Looks like spacing was added by mistake

[aduth]

Looks like spacing was added by mistake

Thanks! Fixed in the rebased e4b84ea.

[ellatrix]

Working great!

[mtias]

Yes, the alignment controls are totally fine on the placeholder. Imagine cases where an editor for a publication lays out the structure of a post, but leaves it up to other people to fill the media. Also could be useful for page templates.

[mtias]

Would it make sense to move this into an empty function?

[aduth]

Would it make sense to move this into an empty function?

What does "empty" mean?

[mtias]

It means when it acts as a placeholder, when no content is yet set. This is going to be a prevalent case for templates down the road.

[aduth]

It means when it acts as a placeholder, when no content is yet set. This is going to be a prevalent case for templates down the road.

Right, but in the sense of treating blocks as rendering always from its state, an imperative "renderNew" doesn't make sense. A block could implement conditions under which it could be considered empty (here, ! url), but it's unclear how we'd want to generalize this. Maybe related to #609, an attribute can be flagged as required and, when missing, use a separate render function like your empty example.

I don't know that introducing this break from edit / save duality really provide a whole lot of value though for what could be equally represented by:

edit: ( { attributes } ) =>
	attributes.url
		? <ImageEdit />
		: <EmptyImageEdit />

[mtias]

That last example looks alright, but I'm mostly concerned with people doing all sort of different things for something that should have a consistent UX. Empty could be just the comment (leaving blocks to implement more fine grained UI handling when specific attributes are missing), which could be a nice way to define a template:

<!-- wp:core/text --><!-- /wp:core/text -->
<!-- wp:core/image --><!-- /wp:core/image -->
<!-- wp:core/button --><!-- /wp:core/button -->

In any case I think forcing block authors to have a separate function for returning the empty render, regardless of whether it is called from edit manually, could be helpful.