Blocks: Introduce block settings menu toggle#2884
Conversation
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
7e5579c to
557b507
Compare
|
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. |
Great idea 👍 |
|
Given the select fix, 👍 👍 from me, worth testing this. |
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). |
editor/block-settings-menu/index.js
Outdated
| className={ toggleClassname } | ||
| onClick={ this.toggleMenu } | ||
| icon="ellipsis" | ||
| aria-label={ __( 'Open Settings Menu' ) } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Actually, I did it intentionally to avoid the tooltip, I thought it was not necessary here, but I can change.
There was a problem hiding this comment.
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( { |
There was a problem hiding this comment.
While we're here, can we refactor this to use the removeBlock action creator?
| dispatch( selectBlock( ownProps.uid ) ); | ||
| }, | ||
| setActivePanel() { | ||
| dispatch( { |
There was a problem hiding this comment.
Per above, maybe also creating a new action creator for this.
| import { selectBlock } from '../actions'; | ||
|
|
||
| function BlockSettingsMenuContent( { onDelete, onSelect, isSidebarOpened, toggleSidebar, setActivePanel } ) { | ||
| const toggleInspector = () => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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.
With the vertical ellipsis we can move the left/right items a bit closer to the block, tighten things up. Looks better.
089d0f7 to
2456fd2
Compare
gziolo
left a comment
There was a problem hiding this comment.
I still need to test it, but it looks very good. I had only nitpicks, which aren't blockers/
| * Returns an action object used in signalling that the user toggled the sidebar | ||
| * | ||
| * @return {Object} Action object | ||
| */ |
There was a problem hiding this comment.
I noticed that we have unit tests for a few existing action creators, should we cover those 2, too?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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? :)
There was a problem hiding this comment.
We don't have a style linter?
| undo: () => dispatch( { type: 'UNDO' } ), | ||
| redo: () => dispatch( { type: 'REDO' } ), | ||
| toggleSidebar: () => dispatch( { type: 'TOGGLE_SIDEBAR' } ), | ||
| onToggleSidebar: () => dispatch( toggleSidebar() ), |
|
|
||
| &:first-child { | ||
| margin-bottom: 4px; | ||
| .editor-block-settings-menu__content &:first-child { |
There was a problem hiding this comment.
It looks like this can be moved to line 17. We have rules for .editor-block-settings-menu__content there.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
49c670c to
c3b8cd1
Compare
|
Good catch @gziolo should be better now |
gziolo
left a comment
There was a problem hiding this comment.
Everything looking great with the last commit. Feel free to merge once Travis will turn green 👍

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