[spike] Tabbed SelectPanel on the stable SelectPanel (faked tabs)#7969
[spike] Tabbed SelectPanel on the stable SelectPanel (faked tabs)#7969joshfarrant wants to merge 2 commits into
Conversation
A reusable git-ref picker: one button opens a stable SelectPanel with Branches/Tags tabs and a single shared search input that filters the active tab's list. Per-tab result counts, single selection, keyboard accessible. Tabs are injected via the panel's subtitle slot and wired with the headless useTab/useTabList hooks. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
|
|
🤖 Lint issues have been automatically fixed and committed to this PR. |
|
🤖 Lint issues have been automatically fixed and committed to this PR. |
Draft — not for merge. Part of a spike comparing how a tabbed SelectPanel (Branches / Tags, one shared search) gets built across Primer's APIs. Same task, same model (Opus 4.8); the API is the only variable:
SelectPanel, pragmatic (tabs work visually but aren't ARIA-associated)SelectPanel, ARIA correctness forced (the component gets abandoned)SelectPanel(composes correctly, ~35 lines of glue)SelectPanel(composes correctly, zero glue)Builds the same picker on the stable
SelectPanel(@primer/react) — the default most teams reach for — asked only to "just build it". Result: ~168 lines, works and is keyboard-usable, but the tabs are a façade. The stable component has no content slot between header and list and owns its listbox internally (id never exposed), so the tablist is smuggled through thesubtitleslot and there is no way to wirearia-controlsto the list. A screen reader can't tell the tabs control anything.See
packages/react/src/SelectPanel/examples/RefPickerV1.tsx. This is the "looks fine, isn't correct" end of the comparison — and the risk: a team could ship this without noticing.