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

Block API: Add support for icons for block categories #10651

Merged
merged 17 commits into from
Oct 27, 2018

Conversation

tyxla
Copy link
Member

@tyxla tyxla commented Oct 16, 2018

Description

This PR adds support for icons for block categories. In addition to supporting Dashicons, the idea is to introduce support for external components, functions and svg icons, in order to allow for third party plugins to be flexible with the icons for the categories they register.

Since <BlockIcon /> already supported all those kinds of methods to define an icon, we're abstracting the functionality to a separate component, and reusing it here and in <BlockIcon />.

How has this been tested?

  • Checkout this PR and build Gutenberg.
  • Open the inserter in a post.
  • Look at the "Common" category.
  • Verify you can see the Dashicon to the right of the "Common" category name.
  • Save at least one reusable block.
  • Verify the reusable blocks category icon is displayed to the right of the category name.
  • Verify that block categories without icons are unchanged.
  • Verify existing block icons in the inserter are unchanged.
  • Verify unit tests pass:
    • BlockIcon tests - npm run test-unit packages/editor/src/components/block-icon/
    • Icon tests - npm run test-unit packages/components/src/icon/
    • All unit tests - npm run test-unit
    • All tests - npm test

Screenshots

Inserter with an icon on the "Common" block category:
https://cldup.com/Eupr3BAnyc.png

"Reusable" category in the inserter with one or more existing reusable blocks:

Inserter with a custom SVG icon on a custom category:
https://cldup.com/etFPNTYIK3.png

(see Automattic/wp-calypso#27878 for testing it)

Types of changes

  • Introduced a new <RawIcon /> component and exposed it.
  • Added tests and documentation for <RawIcon />.
  • Updated <BlockIcon /> to use <RawIcon />.
  • Updated the PanelBody to use <RawIcon /> for block categories.
  • Now passing category icon from inserter menu to <PanelBody />.
  • Now registering the default categories with null icons (no icons).
  • Now displaying the panel body icons on the right side of the panel body title.
  • Moved and updated some tests.
  • TO BE DELETED BEFORE MERGE - added a dashicon to the "Common" block category (204582b).
  • Renamed <RawIcon /> to <Icon />.
  • Made rendering of Dashicon default to a size of 20x20, while keeping 24x24 for the rest of the icon types.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

Notes

  • Since we've added a dashicon to the "Common" block category (204582b) this needs to be deleted before merging.

@mtias mtias added [Type] Enhancement A suggestion for improvement. [Feature] Inserter The main way to insert blocks using the + button in the editing interface labels Oct 16, 2018
@mtias
Copy link
Member

mtias commented Oct 16, 2018

Thanks for working on this. Can we shift the icons to be rendered on the right so that text always aligns visually on the left?

@ZebulanStanphill
Copy link
Member

What if the text was always rendered with space on the left for an icon, so both the icons and the text would always line up?

@folletto
Copy link
Contributor

For reference, this is an old mockup I prepared to avoid the issue with icon alignment:

categories-blocks-branded

The icon on the right avoids having different indentations for the various categories, and at the same time optimizes space. :)

@mtias
Copy link
Member

mtias commented Oct 16, 2018

Note: we should also update:

image

@tyxla
Copy link
Member Author

tyxla commented Oct 17, 2018

Good call, folks - I like the suggestion for the icon on the right side. Updated the PR, here are some screenshots:

Inserter with an icon on the "Common" block category:

"Reusable" category in the inserter with one or more existing reusable blocks:

Inserter with a custom SVG icon on a custom category:

This is ready for another look.

@mtias mtias added this to the 4.2 milestone Oct 22, 2018
import { cloneElement, createElement, Component, isValidElement } from '@wordpress/element';
import { Dashicon, SVG } from '../';

function RawIcon( { icon = null, size = 24, className } ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I suspect the default size property here might have some unexpected side effects on the different types of block icons and the different places where we render them. Mind a sanity check here @jasmussen or @chrisvanpatten as you know more about all the specificities.

Copy link
Contributor

Choose a reason for hiding this comment

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

Interesting timing, I'm actually trying to fix a regression in #10938 (comment) related to this.

24 should be default, but it's okay if an SVG needs to override that and show a 20x20 icon.

If 24 is not default, then that's a bug, as is discussed in that link.

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like we were explicitly showing Dashicons as 20x20 while this PR makes them 24x24 ?

Copy link
Member

Choose a reason for hiding this comment

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

@youknowriad Yeah dashicons should show at 20x20 for weird sizing reasons, but material icons should show at 24x24

@@ -0,0 +1,35 @@
/**
Copy link
Contributor

Choose a reason for hiding this comment

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

👍 Nice little component. Why not just Icon, Thoughts on the name @aduth @mcsf

Copy link
Member

@aduth aduth Oct 23, 2018

Choose a reason for hiding this comment

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

My expectations from the name and description don't really follow into the implementation. If it's "without styles", why do we apply a default width? And an unstyled variation seems more appropriate as a prop of a default component type, e.g. <Icon isUnstyled />.

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, I consider the width an attribute, and not a style 🤷‍♂️

And regarding the component name - Icon felt a little too broad, and I'd probably expect an icon component to be more flexible in terms of how the icon could look. So I'd instead expect to have an Icon component that could use the RawIcon, but add on top of it.

What do y'all think?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd go for either Icon or, considering:

Icon felt a little too broad, and I'd probably expect an icon component to be more flexible in terms of how the icon could look

then I might go with UnstyledIcon.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm good with changing to UnstyledIcon, @aduth @youknowriad does that make sense to you?

Copy link
Member

Choose a reason for hiding this comment

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

I'd probably expect an icon component to be more flexible in terms of how the icon could look.

Can you elaborate on what you mean by this? I'm not sure I follow, and am having a hard time understanding what specifically we're implying in these multiple layers of icon components.

Copy link
Contributor

Choose a reason for hiding this comment

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

I personally still have a small preference for just Icon, if we need to make a distinction between styled and unstyled later, we can add it as a prop.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've been thinking and started gathering a list of what <Icon /> would provide more than <UnstyledIcon />, but I didn't get too far with it.

I guess I'm good with renaming this one to <Icon />, it seems @mcsf and @youknowriad are good with <Icon />, @aduth does that sound well to you?

Copy link
Member

Choose a reason for hiding this comment

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

Works for me. 👍

Copy link
Member Author

Choose a reason for hiding this comment

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

Cool, thanks 👍

Renamed <RawIcon /> to <Icon /> in 3486d0b

I'd appreciate another look when y'all get a chance.

{ title }
{ icon && <RawIcon icon={ icon } className="components-panel__icon" size={ 20 } /> }
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the impact of this change on other usage of PanelBody with icons? Are we ok with all panel body icons being moved to the right or should it be specific to the inserter?

Copy link
Member Author

Choose a reason for hiding this comment

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

Last time I checked, the only usages were in the inserter, and this PR has verified them all.

Whether we're planning to use the PanelBody for something else, and icons would make sense on the right in these cases - perhaps @mtias @jasmussen would know better.

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like it was introduced explicitly for this particular usage (Inserter), so yes, I think I'm fine with the change.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, it was added for the reusable block feature.

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

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

At the moment custom categories are provided using a backend filter IIRC cc @gziolo, how do we provide SVGs from the backend? Do we have the corresponding JavaScript API to add these categories?

@tyxla tyxla force-pushed the try/block-categories-icon-support branch from 8e44061 to d947c68 Compare October 26, 2018 13:17
@@ -14,10 +14,10 @@ exports[`core/embed block edit matches snapshot 1`] = `
aria-hidden="true"
class="dashicon dashicons-embed-generic"
focusable="false"
height="20"
height="24"
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is an issue actually. As outlined here #10651 (comment) Dashicons should be 20x20 by default.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, that's a fair point. I'll reflect this in the component then, and will add some tests too.

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated in c7959cf, thanks for the suggestion!

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

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

I didn't test but looks good to me code-wise :)

@youknowriad
Copy link
Contributor

Tested and works well.

@youknowriad youknowriad merged commit 87732a2 into WordPress:master Oct 27, 2018
@tyxla tyxla deleted the try/block-categories-icon-support branch October 29, 2018 09:25
@tyxla
Copy link
Member Author

tyxla commented Oct 29, 2018

@youknowriad thanks for merging this one!

However, it seems we forgot to remove a commit from the branch before merging. So I've filed a PR for this: #11191.

@designsimply
Copy link
Member

I tested with WordPress 4.9.8 and Gutenberg 4.2.0-rc.1 and didn't see a Dashicon to the right of the "Common" category name. Is this because it's something that needs to be opted into using custom code? Note: I followed the testing steps quite literally and it's possible I'm missing something.

@tyxla
Copy link
Member Author

tyxla commented Oct 31, 2018

@designsimply - it's expected that you don't see it. Adding the Common category icon was for testing purposes for this PR, and even though we merged it with this PR, we reverted it in #11191.

@designsimply
Copy link
Member

Aha. I see. Thank you for the clarification!

@Enchiridion
Copy link

What if the text was always rendered with space on the left for an icon, so both the icons and the text would always line up?

I also would prefer the icon to be on the left. Then assign an icon to each of the default categories, just like the WP admin sidebar. Having them on the right is inconsistent with the rest of WP/Gutenberg UI, and doesn't make finding the category you want any easier since you can't quickly scan a single column.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Inserter The main way to insert blocks using the + button in the editing interface [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.