Chrome: Replace the publish dropdown by a sidebar panel#4119
Chrome: Replace the publish dropdown by a sidebar panel#4119youknowriad merged 5 commits intomasterfrom
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 |
atimmer
left a comment
There was a problem hiding this comment.
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.
Are keyframes local to a CSS file? If not, would this need a gutenberg_ prefix?
There was a problem hiding this comment.
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.
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.
Ok! I'm inclined to leave this issue to a separate PR as it's global to all animations.
mcsf
left a comment
There was a problem hiding this comment.
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.
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.
It needs to be to avoid passing the event as argument to the action creator :)
There was a problem hiding this comment.
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.
Minor, but we could extend mapDispatchToProps:
{
onToggleSidebar: toggleSidebar,
onTogglePublishSidebar: toggleSidebar.bind( null, 'publish' ),
}and replace the prop here with onToggle={ onTogglePublishSidebar }.
| 'is-sidebar-opened': layoutHasOpenSidebar, | ||
| 'has-fixed-toolbar': hasFixedToolbar, | ||
| } ); | ||
| const closePublishPanel = () => onToggleSidebar( 'publish', false ); |
There was a problem hiding this comment.
Minor, similar comment as the previous one. Since these bound action creators don't depend on component data, I'd place them in mapDispatchToProps.
| * @return {Object} Action object | ||
| */ | ||
| export function toggleSidebar( isMobile ) { | ||
| export function toggleSidebar( sidebar, force ) { |
There was a problem hiding this comment.
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.
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: