One filter box, and the tags in it
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 122
- Forks
- 29
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 2
Description
The rail filters by library and by free text, and the two take turns: the header shows either the library Select or the search field, never both, because there is no room for both. Tags are printed on the cards but they are decorative — they take part in the free-text haystack and nothing else.
abernier/examples answered this with a single combobox whose input takes chips from more than one vocabulary at once. This takes that idea, on this corpus.
One control
The chips combobox replaces both branches of the header, and searchOpen, the magnifier and the close button go with them.
Libraries keep ?library= — same name, same labels — but the param becomes a list. An old single-value link parses as a one-element list, so there is nothing to migrate and no compatibility layer to write. Tags arrive as ?tags=, same shape.
What earns a place in the list
An option is offered when it partitions the corpus:
2 ≤ count < 170
which is 56 tags and 17 libraries. @react-three/fiber is on all 170 examples and leaves by the top; the 139 tags carried by a single example leave by the bottom. Neither is named in the code — the rule reads the corpus, so it cannot go stale.
The rule governs what is offered, never what is accepted: a value that is no longer in the list still filters, so a link shared before it still lands where it said it would.
Every chip narrows
Intersection within a vocabulary and across them. Cannon + Rapier gives nothing, which the empty state already covers; every other combination reads the way a filter is expected to read.
The rest of it
- The chips wrap. On a filtered link opened cold the pre-paint skeleton is one line and the real row may be two, so the top of the list moves once at hydration. Accepted, rather than paid for with a pre-paint width estimate that can miss just as badly.
bootNavlearns?tags=. Without it a?tags=link paints all 170 examples with no skeleton at all, then snaps — worse than the shift above.- The keyboard layer is carried over rather than dropped. ⌘F/⌘K and
/are unchanged;Escapegoes in two beats, the popup first and the filters after. The!libraryOpenguard has no translation — for a combobox, open is the ordinary state — and is replaced by the focus test that was already doing the work. - Free text keeps this repo's rule: every typed word has to be found. It is the only path to the 139 rare tags, the authors and the descriptions, none of which are chips. The dropdown keeps the component's own filter — of 73 options exactly one is two words, which is not enough to justify writing a filter.
- The typed query survives the popup closing. Base UI emits
input-clearon close, which would otherwise wipe?q=; it is vetoed.
To check by hand
Nothing here is under test — the website has no suite, and the e2e run shoots examples. The popup inside the mobile sheet, and the two beats of Escape, are the two places to look.
Clickable tag badges are deliberately not in this: they move the list's keyboard rules rather than the header's, and want their own read.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the rail/header filter implementation and trace the existing library selector, free-text search, searchOpen state, and keyboard handling. Then inspect bootNav and the mobile sheet behavior, using the corpus-derived option counts and URL parameters described here as the acceptance criteria. With no test suite, manually check hydration, filtering intersections, the popup in the mobile sheet, and Escape's two-step behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend, web-dev
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100