-
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
Inspector: Use the TabbedSidebar component #63184
base: trunk
Are you sure you want to change the base?
Conversation
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
@@ -316,6 +316,7 @@ function InserterMenu( | |||
> | |||
<div className="block-editor-inserter__main-area"> | |||
<TabbedSidebar | |||
className="block-editor__tabbed-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.
We need this so that we can set a width for only the inserter a the list view.
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.
This ends up compiling to block-editor-tabbed-sidebar block-editor__tabbed-sidebar
which feels like a workaround. How about one of these options:
- Give it a name that describes the 350 width, like:
block-editor-tabbed-sidebar--wide
- Name it as the inserter and list view, i.e.
block-editor-inserter__tabbed-inserter
- Use the className above it to nest the CSS.
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 feels like more code to use a shared component rather than avoid it? Isn't that an issue?
isn't the hideHeader
the same thing as passing an empty header
?
Just wondering if we're actually building the right abstraction basically or if we're bending something to use an abstraction.
IMO The reason for the abstraction is less about minimizing code and more about having consistent UX. At the moment each of these panels looks and behaves differently, and even when we have made efforts to get them in sync they have moved apart again. The hope is that by using the same component we'll have the same UX for all panels. |
Incidentally now I have removed the
|
No, if you don't pass a header then the |
Size Change: -59 B (0%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
</> | ||
) } | ||
</ComplementaryAreaHeader> | ||
{ header !== 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.
This is the only change here - if header is explicitly set to false then we don't output it. This might break other things.
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 don't see a better way to do this either.
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.
Partial review :) I'll do more tomorrow.
selectedTab={ tabName } | ||
defaultTabId={ sidebars.document } | ||
ref={ tabListRef } | ||
closeButtonLabel={ __( 'Close Settings' ) } |
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.
The previous label included the shortcut was Close Settings. ⇧⌘,
@@ -107,22 +103,43 @@ const SidebarContent = ( { | |||
toggleShortcut={ keyboardShortcut } | |||
icon={ isRTL() ? drawerLeft : drawerRight } | |||
isActiveByDefault={ SIDEBAR_ACTIVE_BY_DEFAULT } | |||
header={ 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.
If header
is false
, do we still need the headerClassName
?
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 don't think we need the closeLabel here either.
@@ -316,6 +316,7 @@ function InserterMenu( | |||
> | |||
<div className="block-editor-inserter__main-area"> | |||
<TabbedSidebar | |||
className="block-editor__tabbed-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.
This ends up compiling to block-editor-tabbed-sidebar block-editor__tabbed-sidebar
which feels like a workaround. How about one of these options:
- Give it a name that describes the 350 width, like:
block-editor-tabbed-sidebar--wide
- Name it as the inserter and list view, i.e.
block-editor-inserter__tabbed-inserter
- Use the className above it to nest the CSS.
.block-editor__tabbed-sidebar { | ||
@include break-medium() { | ||
width: 350px; | ||
} | ||
} |
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.
This style also defines the inserter sidebar's width, so it feels like it's blurring the lines of the inserter and list view.
Regarding the X Close button order, pleae see my comment at #59013 (comment) |
@@ -176,20 +194,16 @@ const Sidebar = ( { extraPanels, onActionPerformed } ) => { | |||
); | |||
|
|||
return ( | |||
<Tabs | |||
<SidebarContent | |||
tabName={ tabName } |
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 the tab-related data here should get moved within the SidebarContent rather than passed as props. I think it was done here previously because the Tabs needed be wrapping the SidebarContent. Now that we have a different structure, I think we could move it within.
What?
Implements the new TabbedSidebar component in the Inspector Controls
Why?
For consistency it's good to use the same component for all our tabbed sidebars.
TabbedSidebars
is used for the List View and the Inserter, so this adds it to the Inspector as well.How?
Refactoring to use
TabbedSidebar
.Testing Instructions
Screenshots or screencast