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

Blocks: Introduce block settings menu toggle #2884

Merged
merged 7 commits into from
Oct 9, 2017

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Oct 5, 2017

Replaces the menu at the right of any block by an ellipsis menu.

Screenshots

screen shot 2017-10-05 at 09 37 03

@codecov
Copy link

codecov bot commented Oct 5, 2017

Codecov Report

Merging #2884 into master will decrease coverage by 0.23%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2884      +/-   ##
==========================================
- Coverage   34.06%   33.82%   -0.24%     
==========================================
  Files         192      193       +1     
  Lines        5677     5729      +52     
  Branches      997     1008      +11     
==========================================
+ Hits         1934     1938       +4     
- Misses       3166     3203      +37     
- Partials      577      588      +11
Impacted Files Coverage Δ
editor/actions.js 38.88% <0%> (-2.29%) ⬇️
editor/sidebar/header.js 0% <0%> (ø) ⬆️
editor/block-settings-menu/content.js 0% <0%> (ø)
editor/header/index.js 0% <0%> (ø) ⬆️
editor/block-settings-menu/index.js 0% <0%> (ø) ⬆️
blocks/library/gallery/block.js 9.52% <0%> (-1.59%) ⬇️
blocks/library/audio/index.js 14.54% <0%> (+1.64%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0a02528...8977595. Read the comment docs.

@youknowriad youknowriad force-pushed the try/block-settings-menu-toggle branch from 7e5579c to 557b507 Compare October 5, 2017 08:40
@youknowriad youknowriad requested review from jasmussen and mtias October 5, 2017 08:40
@jasmussen
Copy link
Contributor

Visually I love this, I think it's worth trying.

Accessibility wise, it seems like there are sometimes two tab stops between items in the toolbar for me. This is probably an issue separate to the ellipsis menu, but figured I'd mention it.

I pushed a fix to the placement of a few things.

One thing — can we do it so clicking the ellipsis menu also selects the block? Right now if you only hover over the block, click the ellipsis menu, and move the cursor away from the block, the ellipsis menu collapses, making it fiddly to use.

@youknowriad
Copy link
Contributor Author

can we do it so clicking the ellipsis menu also selects the block?

Great idea 👍

@jasmussen
Copy link
Contributor

Given the select fix, 👍 👍 from me, worth testing this.

@aduth
Copy link
Member

aduth commented Oct 5, 2017

Accessibility wise, it seems like there are sometimes two tab stops between items in the toolbar for me. This is probably an issue separate to the ellipsis menu, but figured I'd mention it.

I've noticed this as well. Thought it might have been something with #2323 shifting focus into popover (tooltips are implemented as popovers), but this is meant to have been fixed with #2771 (including for Tooltip, not just AutoComplete).

aduth
aduth previously requested changes Oct 5, 2017
className={ toggleClassname }
onClick={ this.toggleMenu }
icon="ellipsis"
aria-label={ __( 'Open Settings Menu' ) }
Copy link
Member

Choose a reason for hiding this comment

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

We should assign this prop as label, which has the same effect of applying aria-label, but also enables the tooltip to be shown when hovering the icon.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, I did it intentionally to avoid the tooltip, I thought it was not necessary here, but I can change.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, I guess it's to a broader question of when and where to apply tooltips. My philosophy has been if there is no adjacent text explaining what the icon is for, that a tooltip is a good idea.

} ),
( dispatch, ownProps ) => ( {
onDelete() {
dispatch( {
Copy link
Member

Choose a reason for hiding this comment

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

While we're here, can we refactor this to use the removeBlock action creator?

dispatch( selectBlock( ownProps.uid ) );
},
setActivePanel() {
dispatch( {
Copy link
Member

Choose a reason for hiding this comment

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

Per above, maybe also creating a new action creator for this.

import { selectBlock } from '../actions';

function BlockSettingsMenuContent( { onDelete, onSelect, isSidebarOpened, toggleSidebar, setActivePanel } ) {
const toggleInspector = () => {
Copy link
Member

Choose a reason for hiding this comment

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

As much as I dislike the class component, I feel it has the distinct advantage in avoiding reconciliation which will occur here on assigning the new function reference for every render. Maybe the supposed performance benefits of function components counter-act my own concerns though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I tend to avoid the class components as much as I can, I personally don't mind these "rerenderings" but I don't have any proof saying the functional components even with those functions are faster.

Should we try to set a guideline, or is it fine to have separate styles here?

Copy link
Member

@gziolo gziolo Oct 9, 2017

Choose a reason for hiding this comment

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

Rumors say that functional component was slower in React 15, but it should be comparable in React 16, on the initial render.

There is only one prop which can trigger re-render of this component isSidebarOpened which will cause the first icon to re-render because of this dynamically created function. There is also another option here, we could create this function as 3rd param in the connect function.

I commented this already in other PR. I don't like the fact that we have a choice of the component syntax in the first place. It seems like a class component is a better choice here, but it's hard to measure performance implications. We could use mergeProps from connect more often, but this brings another set of issues to the table :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Rumors say that functional component was slower in React 15, but it should be comparable in React 16, on the initial render.

Actually, I saw a benchmark showing that the functional components are 15% faster than the class components but unless you benchmark your self, this is irrelevant.

I'm very much in favor of avoiding premature optimization vs simpler code. And I have to admit I don't like classes that much.

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

I still need to test it, but it looks very good. I had only nitpicks, which aren't blockers/

*
* @return {Object} Action object
*/
export function toggleSidebar() {
Copy link
Member

Choose a reason for hiding this comment

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

I noticed that we have unit tests for a few existing action creators, should we cover those 2, too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah! I know and I've written some of these, but honestly, I'm not sure these add any value for action creators just returning an action with the arguments as properties of the object.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, sometimes it's hard to justify the need for writing tests, but at the same time it's very easy to write them. It's your call, as I mentioned already. It's not a blocker.

}

.editor-block-settings-menu__toggle {
transform: rotate(90deg);
Copy link
Member

Choose a reason for hiding this comment

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

Do we add spaces inside all parentheses also in CSS? I'm not sure, just checking. If yes, what has happened to you style linter? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't have a style linter?

Copy link
Member

Choose a reason for hiding this comment

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

Haha, okey :)

undo: () => dispatch( { type: 'UNDO' } ),
redo: () => dispatch( { type: 'REDO' } ),
toggleSidebar: () => dispatch( { type: 'TOGGLE_SIDEBAR' } ),
onToggleSidebar: () => dispatch( toggleSidebar() ),
Copy link
Member

Choose a reason for hiding this comment

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

New action creator 👍

@@ -35,7 +49,7 @@
display: block;
}

&:first-child {
margin-bottom: 4px;
.editor-block-settings-menu__content &:first-child {
Copy link
Member

Choose a reason for hiding this comment

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

It looks like this can be moved to line 17. We have rules for .editor-block-settings-menu__content there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Don't you think it makes more sense to keep it in .editor-block-settings-menu__control because it's applied to this class when it's first on the list? I can see arguments for both which makes the choice difficult.

Copy link
Member

@gziolo gziolo Oct 9, 2017

Choose a reason for hiding this comment

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

It takes some time to process those class names either way. CSS is complicated. We could add another class name, but having a section .editor-block-settings-menu__inspector just to change the margin is most likely be too much here.

@youknowriad youknowriad force-pushed the try/block-settings-menu-toggle branch from 49c670c to c3b8cd1 Compare October 9, 2017 11:51
@gziolo
Copy link
Member

gziolo commented Oct 9, 2017

I found only one small thing that might require a fix:

screen shot 2017-10-09 at 14 15 47

I think it should be displayed Close Setting Menu when the menu is in the opened state.

@youknowriad
Copy link
Contributor Author

Good catch @gziolo should be better now

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

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

Everything looking great with the last commit. Feel free to merge once Travis will turn green 👍

@gziolo gziolo changed the title Try/block settings menu toggle Blocks: Introduce block settings menu toggle Oct 9, 2017
@youknowriad youknowriad merged commit 8557b53 into master Oct 9, 2017
@youknowriad youknowriad mentioned this pull request Oct 9, 2017
5 tasks
@aduth aduth deleted the try/block-settings-menu-toggle branch October 9, 2017 13:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants