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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <[email protected]>
Co-authored-by: mirka <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: 0 B

Total Size: 7.66 MB

_{compressed-size-action}

@WordPress/gutenberg-components would you be able to take a look at this one?

My initial motivation for adding this kind of runtime check was simply to stop consumers from using this as a faux tabs component. Basically, to prevent consumers from using it for tablist-like styling, and not passing tab panels at all. This is a much narrower scope than wanting to catch other kinds of misconfiguration errors, like value-level matching and duplicate detection.

In that light, I notice a lot of added complexity due to adding more rigorous validation than necessary to prevent the original problem that motivated a runtime check. To prevent the original problem, I feel like all we need is a counter for tabs and panels, and check that the number matches.

Do you think it's worth the complexity to add this level of validation? Has that been a problem, in your experience?

Over the years, we've definitely witnessed many misuses of Tabs, I guess because of two reasons:

• It was one of the first compound components, therefore more complex/fragmented/easier to only use partially
• it implements a functionality often needed (some sort of lightweight memory router), which folks often used even when there wasn't a need for

As we add more compound components, given that we're trying to systematically prevent misuse (especially with extra lint rules), I think that the changes in this PR go in the same direction; in that sense, I think it's a good approach, especially since most of the code is a no-op in production mode.

For example, we already implemented a similar pattern to ensure that Dialog consumers render a Dialog.Title.

So, overall, despite the code definitely bringing complexity, I can also see the benefits, especially if we can manage to refactor the code to a shared utility (to limit the growing complexity) and apply it consistently. What do you think?

I think there's a difference between misuse that is often unnoticeable from the developer (like accessibility issues), and misuse that they will notice as bugs.

Is the duplicate or mismatched panels case a noticeable problem or an unnoticeable problem? Like, does Tabs actually function with duplicate or mismatched panels? If it simply doesn't work, the developer will notice soon enough, without us having elaborate logic to catch them early.

I'm just playing around in the Storybook on trunk, but duplicate tab values crashes already, and mismatched tabs don't work. So if that's truly the case, it seems like we'd be adding complexity for slight developer convenience, not for quality assurance.

So my question is "are there actual abuse vectors that we can prevent by catching duplicate or mismatched tabs"? And by "abuse" I mean things that seem to work but are actually accessibility issues. If yes, I can agree it's worth the trouble.

I guess the main patterns with Tabs that we want to prevent are:

1. not rendering sub-components inside Tabs.Root
2. only rendering a TabList + individual Tabs, but then rendering custom UI instead of TabPanels, basically using Tabs as a memory router

Base UI will throw an error for the missing Tabs.Root, but pattern no. 2 won't be flagged.

Do you think that scenario is enough of a reason?

2. only rendering a TabList + individual Tabs, but then rendering custom UI instead of TabPanels, basically using Tabs as a memory router

Do you think that scenario is enough of a reason?

Yes, this is the exact case I wanted to prevent in the first place, which I think can be caught by a simpler strategy ("a counter for tabs and panels, and check that the number matches"). Wanting to catch duplicate/mismatched tab values on top of that is adding a good amount of complexity that doesn't seem warranted.

Flaky tests detected in c77ecc2.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23242388604
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js
• [Flaky Test] should paginate #69568 in /test/e2e/specs/site-editor/user-global-styles-revisions.spec.js

@mirka I updated (vastly simplified) the code to apply the check that you suggested. It's a good idea to start simple and add complexity only if needed.

I pushed changes, PR should be ready for a final round of review

@mirka I switched it back to throwing an error, and updated PR description and error message.

We can always tweak throwing or warning later, in case there are legitimate reasons to relax things around.

E2E tests failures appear un-related (the `Tabs component is not used yet in Gutenberg)