-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Chrome: Replace the publish dropdown by a sidebar panel #4119
Conversation
77c2ffe
to
82963bd
Compare
Yaaaassss! I love this. Given we're going with a "combined popover/sidebar", is it possible to make it so if the settings sidebar is toggled off, you still "push in the text"? Right now it covers it: Also — is it possible to add animation at this point? Doesn't have to be in this PR, but structure wise, can the thing animate in from the right? Thanks so much for working on this! |
0a8d83a
to
240178f
Compare
@jasmussen Ok so I had to rethink the redux sidebar state to allow multiple sidebars to be able to fix the text margin issue. It should work now. I also added a small animation, let me know what you think |
a274aeb
to
ae83845
Compare
I love the recent change. I'd speed up the animation to be double the speed, at most .2s. But 👍 👍 I think this is a great first step. Next steps could be:
We need to think about where to put the "Switch to Draft" button when it can't sit in the dropdown, but we'll solve that I'm sure. |
To be clear, those next steps don't have to be in THIS PR, they can be done separately I think. |
Tha animation is already .2s, should I update it to 0.1s |
Ah cool. Yeah let's try .1s |
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.
Looks good to me 👍🏻. One small question about CSS @keyframes
.
animation: slide_in_right 0.1s forwards; | ||
} | ||
|
||
@keyframes slide_in_right { |
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.
Are keyframes local to a CSS file? If not, would this need a gutenberg_
prefix?
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.
Mmmm good question, I guess this applies to all of our animations. I wonder if there's a way to nest these animations. If not, it makes sense to add a prefix for me.
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.
cc @jasmussen
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 do think animations are globally registered, so if registered once it's available everywhere the CSS is loaded.
It'd be nice to either have reusable animations, or well scoped ones.
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.
Ok! I'm inclined to leave this issue to a separate PR as it's global to all animations.
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.
Looks great! (Got merged as I was typing this. 😄 )
Tangent: Design-wise, the dropdown chevron will go away, as it no longer reflects the impending animation:
I see, from the parent issue's mockups, that we can adopt Publish…
or Publish!
instead, without any other visual cue. That's fine with me. However, I'm wondering if we can use what the Customizer did for widgets as inspiration, with the ¼-turn spinning icon:
/> | ||
<IconButton | ||
icon="admin-generic" | ||
onClick={ () => onToggleSidebar() } |
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.
Does the function need to be bound? Perhaps this is an artefact of something else? I'd expect onClick={ onToggleSidebar }
.
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 needs to be to avoid passing the event as argument to the action creator :)
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.
facepalm — obviously. I mean, you could just do some insane stuff in mapDispatch
like toggleSidebar.bind( null, undefined, false )
, but that's just idiotic. 😄 The arrow is naturally better. exits slowly
<PostPreviewButton /> | ||
<PostPublishPanelToggle | ||
isOpen={ isPublishSidebarOpened } | ||
onToggle={ () => onToggleSidebar( 'publish' ) } |
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.
Minor, but we could extend mapDispatchToProps
:
{
onToggleSidebar: toggleSidebar,
onTogglePublishSidebar: toggleSidebar.bind( null, 'publish' ),
}
and replace the prop here with onToggle={ onTogglePublishSidebar }
.
'has-fixed-toolbar': hasFixedToolbar, | ||
} ); | ||
const closePublishPanel = () => onToggleSidebar( 'publish', false ); |
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.
Minor, similar comment as the previous one. Since these bound action creators don't depend on component data, I'd place them in mapDispatchToProps
.
*/ | ||
export function toggleSidebar( isMobile ) { | ||
export function toggleSidebar( sidebar, force ) { |
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.
Also minor, but both arguments are nouns, yet they express different things, IMO. sidebar
is the object of the action, while force
is circumstantial. My suggestion would be shouldForce
, in keeping with the convention for booleans. (To be super strict, one could rename the former to sidebarName
, but I'm fine with sidebar
.)
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 think forcedValue
is better than shouldForce
because it represents the value and not a flag of whether to force or not
@mcsf I believe the design plan is that the Publish menu uses an ellipsis instead of a chevron. cc @jasmussen |
This PR is the first step towards the updated publish flow #3496 (comment)
In this initial iteration, I'm not updating the current flow, just replacing the current dropdown by a sidebar panel.
Next PRs will focus on: