feat: add segmented control radio and tabs

[nats12]

Short description

Adds the Todoist segmented-control patterns to Reactist while retaining the existing compound Tabs API for compatibility.

• Adds options-based SegmentedControlRadio and SegmentedControlTabs components with controlled and uncontrolled selection.
• Supports disabled options, icons, rich labels, tooltips, extra labels/icons, link-rendered tabs, panel render modes, alignment, and full-width layouts.
• Moves the existing compound Tabs component onto the shared segmented-control styling, removes its old sliding indicator implementation, and marks the API as deprecated in favor of SegmentedControlTabs.
• Adds React 18/19 tests, accessibility coverage, and Storybook examples, organized as Segmented Control → Radio/Tabs and Tabs → Compound API; the compound API docs display Reactist's deprecated badge and migration note.
• Handles equal-height wrapped labels for narrow full-width consumers such as Todoist Developer Options.

Locally verified through Reactist Storybook and in Todoist Web via yalc.

References

• https://github.com/Doist/frontend-issues/issues/1350

Demo

Old one deprecated

PR Checklist

• Added tests for bugs / new features
• Updated docs (storybooks, readme)
• Reviewed and approved Chromatic visual regression tests in CI

[nats12]

@frankieyan before I send this off to review, it has been a while so wanted to check our process on this. I haven't removed the current Reactist Tabs from in here yet. So currently both exist:

This is largely to not break consumers.

Would we mark as deprecated, then once this is merged, and OUR consumers are on the latest component, then completely remove?

[frankieyan]

@frankieyan before I send this off to review, it has been a while so wanted to check our process on this. I haven't removed the current Reactist Tabs from in here yet. So currently both exist:

This is largely to not break consumers.

Would we mark as deprecated, then once this is merged, and OUR consumers are on the latest component, then completely remove?

Yeah! I think marking the old tabs as deprecated first would be the way to go.

I'd go with adding a badge to the stories:

reactist/.storybook/badges/README.md

Line 22 in eeac516

badges: ['partiallyAccessible', 'deprecated']

And marking the components themselves as deprecated with jsdoc: https://jsdoc.app/tags-deprecated

But not rename the button to avoid a breaking change for now (but of course if you'd like to offload the renaming in consumers or even migrate right way to an agent, that's fine too!)

[doistbot]

⚠️ PR size is large: Review quality may be affected

👋 @nats12 This PR is large enough that Doistbot's review may miss details.

Current diff: 1,177 review-load lines across 12 files (+1177 / -225). I will still run the review, but this would be easier for your colleagues to review as smaller PRs or a PR stack 😅

ℹ️ To make it easier to review, the recommended diff size is < 750 review-load lines and < 25 files changed

To be mindful of their time I would suggest you split this PR

Steps for splitting the PR:

1. Put mechanical refactors, generated updates, and dependency changes in their own PRs.
2. Open the first PR against main.
3. Branch the next PR from the previous PR branch, then set its GitHub base branch to that previous branch.
4. Merge the stack from bottom to top.

You can use your agent of choice (Codex/Claude etc) to help you with the split 😊 Just point them to this comment and ask them Can you please help me create a logical PR stack from this PR?

[nats12]

Yeah! I think marking the old tabs as deprecated first would be the way to go.

I'd go with adding a badge to the stories:

Thanks @frankieyan, ended up doing this. And I've added you as second reviewer on this one, hope that's OK.

[doistbot]

This PR adds SegmentedControlRadio and SegmentedControlTabs components to Reactist, moves the compound Tabs onto shared segmented-control styling, and deprecates the old Tabs API with migration notes.

I also included a few optional follow-up notes in the details below.

Optional follow-up notes (4)

• src/segmented-control/segmented-control.tsx:185: The @deprecated JSDoc says "consumers of the initial Reactist port can migrate without a breaking change." Since this is the first time SegmentedControl appears in Reactist, there are no existing consumers. The comment should describe why the alias exists (e.g., to match the name used during development in Todoist via yalc) rather than implying pre-existing external usage.
• src/segmented-control/segmented-control.test.tsx:17: flushAnimationFrames (and the near-identical renderSegmentedControl/renderSegmentedControlTabs wrappers) are duplicated verbatim in segmented-control.test.tsx and segmented-control-tabs.test.tsx. Reactist already centralizes shared test utilities in src/utils/test-helpers.tsx (e.g. flushMicrotasks). Consider extracting flushAnimationFrames there so both files import it, matching the existing pattern and avoiding drift between the two copies.
• src/segmented-control/segmented-control-tabs.tsx:47: ControlledTabsSelectionProps and UncontrolledTabsSelectionProps (L47-57) are structurally identical to ControlledSelectionProps/UncontrolledSelectionProps in segmented-control.tsx (L54-64). Since this file already imports AriaLabelProps from ./segmented-control, consider exporting and reusing the base controlled/uncontrolled types instead of redefining them.
• src/segmented-control/segmented-control.tsx:114: The justifyContentAlignMap lookup is defined identically here and in tabs.tsx (TabList, line 207). Both map the same 'start' | 'center' | 'end' → BoxJustifyContent values for the same align prop. Extracting a shared helper (e.g. in utils/common-types or a small shared module) would prevent the two from drifting if the alignment options change.

_{Share Feedback • Review Logs}

[nats12]

Addressed the Doistbot review feedback in f8ee8fe:

• Preserved Tab inline styles in the fallback render and added a regression test.
• Verified uncontrolled SegmentedControlTabs keyboard navigation switches the visible panel.
• Reworded the temporary SegmentedControl alias deprecation note so it does not imply released consumers.
• Moved the shared animation-frame flush helper into test-helpers.
• Reused the controlled/uncontrolled selection prop types across radio and tabs.
• Shared the alignment type and justify-content mapping between the radio and compound-tab implementations.

The PR-size suggestion was not applied: the radio/tabs APIs and their shared styling are one cohesive migration, while splitting now would make their dependency relationship harder to review and land.

Validation: full React 19 and React 18 suites pass (46 suites, 631 passed and 1 skipped per version), along with lint, both type-checks, and React Compiler tracking.

[Bloomca]

New segmented tabs have issues at full width in the Storybook (I assume because the container constraints them):

Otherwise, looks good. I left a few comments regarding potentially better type placements

[Bloomca]

This could be limiting the full width

[Bloomca]

Same here, potentially it limits the full width

[Bloomca]

My original reaction was that the name is too generic, but then I checked and it actually describes it very well. But I feel like we should move it somewhere else, maybe in src/utils/common-types.ts?

[Bloomca]

I think we should preserve the original comment:

/* ref: https://www.a11yproject.com/posts/how-to-hide-content/ */

[frankieyan]

Something I didn't realize with the SegmentedControl is that it's still using Ariakit 😅 so this would be a lateral move for us. On the bleeding issue Seva pointed out, it also happens in the developer options, but I thought that was still using the old Tabs - which isn't actually better because it does this:

Would it be worth pivoting to the BaseUI Tabs and RadioGroup instead?

In small viewports, I wonder if we could adopt the pattern that the template gallery uses so that the control is scrollable/draggable: