-
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
Components: replace TabPanel
with Tabs
in the Block Inserter
#56918
Conversation
Size Change: +36 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
Flaky tests detected in b554602. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7198837435
|
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.
Because the items in the tabpanels are focusable, I've applied focusable=false so focus can skip the panel itself.
This represents a change from the current behaviour and it makes sense in principle to me (although always better to get a blessing from @andrewhayward to make sure)
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.
Looking good 🚀
We can probably merge and revisit the isFocusable
decision in a follow-up in case Andrew (or anyone else)'s advice is to keep the current behaviour instead
5fe8b67
to
b554602
Compare
Related to #55360 (comment) from @youknowriad , this PR seems to have introduced a performance regression in the "inserter opening" metric (https://www.codevitals.run/project/gutenberg). I wonder if maybe some of this could be obviated by using the In any case, we may have to slow down integrating @diegohaz , could you think of anything in particular that may be causing the slower perf here? A few folks noticed the high amount of nested context providers in the React tree and were wondering if maybe that could be a reason. |
Multiple context providers should not pose a problem. Did the prior version render only the selected tab panel? If that's the case, it's probably why. By default, Ariakit renders all tab panels and simply toggles their visibility using You can choose to render only the selected tab panel by controlling its Alternatively, you can conditionally render the const isVisible = tab.useState((state) => state.selectedId === props.tabId);
<TabPanel tabId={props.tabId}>
{isVisible && props.children}
</TabPanel> |
What?
Replaces the legacy TabPanel component with the new Tabs component.
Because the items in the tabpanels are focusable, I've applied
focusable=false
so focus can skip the panel itself.Why?
Part of the work outlined in #52997
How?
TabPanel
is replaced byTabs
and its sub-components.The data to render the contents of the individual
tabpanel
s was previously delivered via a render function, because that's howTabPanel
operates. Because a function is no longer required, I've converted that data into a simple object, which I hope will be easier to parse for anyone updating this code in the future.Testing Instructions
Testing Instructions for Keyboard
ctrl + `
until you're focused on the top toolbar