-
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 editor's ColorGradientControl
#56351
Conversation
Size Change: +22 B (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
} | ||
> | ||
<Tabs.TabList> | ||
<Tabs.Tab id={ 'color' }> |
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.
When passing a string prop, we should just pass it as a string, that way it won't be necessary to tell React to further evaluate it as an expression. That suggestion applies to the rest of the strings that are passed as expressions in this PR.
<Tabs.Tab id={ 'color' }> | |
<Tabs.Tab id="color"> |
Furthermore, is it possible that the ID we're passing here may already be in use on the same page because it's a rather common one? Should we prefix it with something?
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.
Good points, I should have added a comment to that bit.
Passing a string here will trigger ESLint's error asking for useInstanceID
, which I don't actually want to do. I should probably add an ignore comment with an explanation rather than going around it in this admittedly opaque way.
Tabs
applies useInstanceId
internally, so there id clashes shouldn't happen but, this comment has me realizing I should really take another look at that part of the component's API, as it really isn't going to be clear to consumers that will run into this exact situation. Putting this on my todo/followup list for Tabs.
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.
Thanks for looking into it!
packages/block-editor/src/components/colors-gradients/control.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/colors-gradients/control.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/colors-gradients/control.js
Outdated
Show resolved
Hide resolved
2f16b4a
to
4b48fe1
Compare
Flaky tests detected in e0a7f53. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7106110913
|
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.
🚀
501d31e
to
e0a7f53
Compare
I've addressed the final CI failures, which were mobile/native tests. The problem was that calling the How I Got Here
Question |
Thanks for the ping and including such a great overview in your comment! 🙇🏻 From what I gather from the situation, the workaround seems appropriate. I believe the mobile team has a couple of PRs open working to address the circular dependencies, so hopefully we can remove the workaround in the near future. It does not appear that the mobile editor relies upon For good measure, I added the "Mobile App - Automation" label to this PR so that the larger E2E test suite runs in wordpress-mobile/gutenberg-mobile#6447. If the CI checks pass on the sibling PR, I believe we should merge this PR. 🚀 |
Excellent, thank you so much @dcalhoun! I'll monitor those CI checks, and once they have passed I'll get this PR merged. |
The CI checks in wordpress-mobile/gutenberg-mobile#6447 passed. We are good to merge. 🚀 |
What?
Replaces the legacy
TabPanel
component with the newTabs
component.Why?
Part of the work outlined in #52997
How?
TabPanel
is swapped out forTabs
and its sub-components. This eliminated the needs for aTABS_SETTINGS
array. I did opt to keep thetabPanels
array to make it cleaner to address the two different cases where those panels are rendered (one as aTabPabel
insideTabs
, an one as a standalonediv
when only one option is being rendered.So far unit tests don't seem negatively impacted by these changes, but I'm going to wait for the full CI suite to run. Similarly I didn't see anything in the related styles that needed to be removed as a result of this migration.
Testing Instructions
Styles
tab.ColorGradientControl
looks and behaves the same way it does ontrunk
ColorGradientControl
and then open it again, it selects the right tab (ie, if the block has a gradient background, it should automatically open to the Gradient tab)Testing Instructions for Keyboard
ColorGradientControl
opens.Solid
andGradient
tabstabpanel
. It should focus the custom color button or gradient control points)