-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
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.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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( { |
There was a problem hiding this comment.
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( { |
There was a problem hiding this comment.
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 = () => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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.
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
There was a problem hiding this 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() { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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? :)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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() ), |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
49c670c
to
c3b8cd1
Compare
Good catch @gziolo should be better now |
There was a problem hiding this 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 👍
Replaces the menu at the right of any block by an ellipsis menu.
Screenshots