Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Allow classnames to be specified for icon
To be able to color icon controls, needed to support passing
in additional classnames to the IconButton.
  • Loading branch information
mkaz committed May 4, 2017
commit 0017e3ab2a8cb66ebd8f1ce72d2f614243b1a0e2
2 changes: 1 addition & 1 deletion editor/components/toolbar/index.js
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ function Toolbar( { controls } ) {
} }
className={ classNames( 'editor-toolbar__control', {
'is-active': control.isActive
} ) } />
}, control.classNames ) } />
Copy link
Member

Choose a reason for hiding this comment

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

We're not using this?

Copy link
Member Author

Choose a reason for hiding this comment

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

The change that used the classname got backed out, it was created to pass a class to the control icon and provide a different color. It could be useful to leave for others to be able to tweak controls.

Copy link
Member

Choose a reason for hiding this comment

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

It could be useful to leave for others to be able to tweak controls.

We can always reintroduce it if it proves to be useful, but I'm generally against introducing functionality we expect could be useful but not actually use (YAGNI).

If and when it can be shown to provide value, I think there could also be a discussion on the naming and shape of classNames. Is it a className (singular) string? A classNames (plural) array of strings?

Copy link
Member

Choose a reason for hiding this comment

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

The flip side of this argument might be that we can't always anticipate the needs of a plugin implementing a block. To this point, I think we'll have pretty good exposure in the course of implementing a core set of blocks to the sorts of needs we'll need to accommodate. Or at least, we should consider whether this is an extension point we want to offer. Class names in particular are pretty susceptible to conflict (plugins trying to use the same name), and we may end up doing a disservice by exposing it. There could be alternative solutions such as inline styles, or more built-in customization such as icon color in your original usage.

) ) }
</ul>
);
Expand Down