Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement image block placeholder #566

Merged
merged 1 commit into from
May 2, 2017
Merged

Conversation

aduth
Copy link
Member

@aduth aduth commented Apr 28, 2017

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.

Placeholder Image

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.

@aduth aduth added the [Feature] Blocks Overall functionality of blocks label Apr 28, 2017
@ellatrix
Copy link
Member

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.

.blocks-image__placeholder-label {
display: flex;
align-items: center;
justify-content: center;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like spacing was added by mistake

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like spacing was added by mistake

Thanks! Fixed in the rebased e4b84ea.

@ellatrix
Copy link
Member

Working great!

@mtias
Copy link
Member

mtias commented Apr 28, 2017

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.

@@ -72,6 +75,23 @@ registerBlock( 'core/image', {
edit( { attributes, setAttributes, focus, setFocus } ) {
const { url, alt, caption } = attributes;

if ( ! url ) {
return (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

What does "empty" mean?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 />

Copy link
Member

@mtias mtias May 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants