-
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
Tabs: replace id
with new tabId
prop
#56883
Conversation
Size Change: +1 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
Flaky tests detected in a5f89d7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7143493811
|
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 testing well, both in Cover block's settings and in SB. 🎉
One thing I just wanted to check on:
The id
property in the above Tab components would now be the equivalent of the tabId
prop, right? If so, I think it would be helpful to update the naming in the tests too, to make it clearer it's not another kind of id
.
One fallback of the current approach is that a consumer of Maybe we should revisit the decision of adding the prefix instead, and therefore continue passing the |
On second thoughts, consumers of the component should probably be able to use react So the suggested approach of using
It kind of is necessary, if we're adding the |
220dd4a
to
e998591
Compare
I like it. Done in 4dd2f10573, thanks!
Cool. For the sake of answering questions closing loops in case this thread is ever revisited though, the main drawback I can think of is potential id collisions. They probably aren't likely, but the current approach avoids the danger entirely. An added benefit to the ref idea you've mentioned for grabbing ids is that it feels a little more resilient that way. On the off chance an Id got changed, the ref would keep up with that and not need to be updated the way a hardcoded id value would. |
I thought about it, and wondered if that should be the responsibility of the consumer (like for the majority of other components), rather than the component itself. It just felt a bit "off" to me that we're making an API change because of an eslint rule |
e998591
to
a5f89d7
Compare
What?
id
prop onTabs.Tab
andTabs.TabPanel
with a newtabId
prop.Why?
As first noted on a recent PR, passing id's to these sub-components as strings is problematic because it triggers our eslint rule recommending
withInstanceId
.The
Tabs
components already utilize an internally instanced id.How?
Replace
id
withtabId
on the two sub-components that use it, andOmit
id
from the intrinsic attributes applied to those components.There is one active implementation of
Tabs
that is also updated in this PR to use the new prop.note: omitting
id
isn't strictly necessary, but felt like another helpful pointer towards the new prop, in addition to the existing eslint warning. Happy to remove theOmit
if it would be better not to have it.Testing Instructions
npm run storybook:dev and confirm all
Tabs` stories still render the correct content for each tabTODO:
There are two other existing
Tabs
implementations that will need to be updated based on this PR:Tabs
in editor settings #55360TabPanel
withTabs
in the editor'sColorPanel
#56878If either of those PRs merges before this one, this PR needs to be updated to address the props in the affected files.
If either of the PRs has not merged before this one, that PR will need to be rebased and updated to use the new prop.