docs(RadioGroup): scope Radio.Tabs to form fields - #1369
Merged
tenphi merged 2 commits intoAug 27, 2026
Merged
Conversation
The Best Practices section recommended `Radio.Tabs` for compact toolbars and reserved traditional radios "for forms", placing Radio.Tabs on the non-form side. That inverts what the component actually is: every RadioGroup variant runs through `useFieldProps` and `wrapWithField`, so `Radio.Tabs` is a form control carrying field wiring and radiogroup semantics that a toolbar never uses. `Tabs` already ships `type="radio"`, which renders the same chrome and owns the panels it switches between. The doc line kept costing review rounds in Cloud, where the opposite rule holds — authors could cite a live doc line supporting the choice a reviewer was asking them to change. Adds a "When not to use" section with the decision matrix, rewrites the two Best Practices entries, and points the `radio` tab type back at Radio.Tabs so the guidance holds from either doc. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Contributor
📦 NPM canary releaseDeployed canary version 0.0.0-canary-cb8163d. |
Contributor
🏋️ Size limit report
Compared against main at b08530e — run 33004571191, 2026-08-26T19:19:48Z.To see which modules changed, download the size-limit-statoscope-report artifact from this run and open report.html. |
Contributor
🧪 Storybook is successfully deployed!
|
…diotabs-for-the-non-form-case
tenphi
deleted the
andrew/cub-4129-radiogroup-docs-recommend-radiotabs-for-the-non-form-case
branch
August 27, 2026 09:50
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Describe changes
Settles CUB-4129 — a docs-vs-guidance conflict, not a bug.
The RadioGroup Best Practices section said:
with a
label="View"list/grid toolbar switcher as the example. Cloud'sui-reviewruleset (radio-tabs-only-in-forms) says the opposite for exactly that case, so authors kept landing on PRs where a live doc line supported the choice the reviewer was asking them to change — it happened on two PRs the same day.Resolved in favour of the Cloud rule, because the code backs it rather than the doc:
RadioGroupvariant —tabsincluded — runs throughuseFieldProps(RadioGroup.tsx:91) andwrapWithField(RadioGroup.tsx:178).Radio.Tabsis unavoidably a form control, carrying field wiring,role="radiogroup"semantics, andFormvalidation.Tabsalready shipstype="radio"(Tabs/types.ts:12), which renders the same chrome, owns the panels it switches between, and carries none of the field machinery.A toolbar view switcher pays for wiring it never uses, so the doc line was the thing that was wrong.
Changes
RadioGroup.docs.mdxRadio.Tabs; in a Form otherwise →type="button"; not a Form →Tabs).label="View"list/grid example that triggered this is now the explicit don't, shown beside itsTabs type="radio"replacement.nameprop, since it is a field.Tabs.docs.mdxradiotype bullet now names itself as the non-form choice and points back atRadio.Tabs, so the guidance holds from whichever doc an author lands on first.Checklist
Not applicable — docs-only change, no runtime code touched: tests/stories, changeset (matching the precedent of
fa0e4670, a docs-only.docs.mdxcommit), library size threshold.Closes: CUB-4129
Other information
docs/components/fields/RadioGroup.md; that file is generated from the.docs.mdxsources byscripts/prepare-docs.mjsatprepack, so the sources are what changed here. Regeneration was verified locally — the Storybook/docs/...--docslinks rewrite to relative paths as intended.scripts/prepare-docs.mjsoutsideprepacksilently dirties the working tree.docs/glazeanddocs/tastyare tracked as symlinks intonode_modules, and the script replaces them with real copied directories (prepare-docs.mjs:439). Restored here, but it will catch out anyone who runs the script by hand.🤖 Generated with Claude Code
Note
Low Risk
Documentation-only changes to
.docs.mdxfiles; no runtime or API behavior is modified.Overview
Aligns Storybook docs with Cloud’s
radio-tabs-only-in-formsguidance so authors aren’t steered towardRadio.Tabsfor toolbar-style view switchers.In RadioGroup docs, it adds that every variant (including
Radio.Tabs) is a form control, a When not to use section with a decision table (Form+ gates fields →Radio.Tabs; inFormotherwise →type="button"; outsideForm→Tabswithtype="radio"), and rewrites Best Practices #3 and #9 so the old list/gridRadio.Tabsexample is the explicit anti-pattern besideTabs type="radio". The Tabs Group example now includes anameprop and a caveat about form-only use.In Tabs docs, the
radiotype bullet now describes non-form compact switchers and cross-links toRadio.Tabsfor form values.Reviewed by Cursor Bugbot for commit e4e0916. Bugbot is set up for automated code reviews on this repo. Configure here.