fix(ui-kit): make Carousel's keyboard handler orientation-aware#8337
Conversation
Carousel accepts orientation="horizontal"|"vertical" and every other part of the component branches on it (content margins, item padding, prev/next button position and rotation), but handleKeyDown was hardcoded to ArrowLeft/ArrowRight regardless. On a vertical carousel -- whose prev/next buttons already point up/down -- ArrowUp/ ArrowDown did nothing while ArrowLeft/ArrowRight (meaningless in that layout) still scrolled. Resolve orientation once (reusing the exact expression CarouselContext already exposes) and bind ArrowUp/ArrowDown -> scrollPrev/scrollNext for vertical, keeping ArrowLeft/ArrowRight for horizontal (the unchanged default). Adds carousel.tsx's first tests: vertical uses Up/Down (not Left/Right), horizontal unchanged.
|
🚨 Contributor flagged. Click here for more info: Superagent Dashboard |
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
|
Warning ⏸️ LoopOver review result - manual review recommendedReview updated: 2026-07-24 15:00:49 UTC
Review summary Nits — 3 non-blocking
Flagged checks (non-blocking)
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionAddressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Visual preview
Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy. Scroll preview
A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|


What & why
Closes #8308.
Carousel(packages/loopover-ui-kit/src/components/carousel.tsx) acceptsorientation?: "horizontal" | "vertical", and every other part of the component branches on it —CarouselContent(-ml-4vs-mt-4 flex-col),CarouselItem(pl-4vspt-4), andCarouselPrevious/CarouselNext(reposition + rotate 90°). The keyboard handler was the one exception:handleKeyDownwas registered unconditionally and only responded toArrowLeft/ArrowRight.So on a
orientation="vertical"carousel — whose prev/next buttons already point up/down —ArrowUp/ArrowDowndid nothing, whileArrowLeft/ArrowRight(no on-screen meaning in that layout) still scrolled. A keyboard user got no arrow navigation matching what they see.The fix
Resolve orientation once — reusing the exact expression
CarouselContextalready exposes (orientation || (opts?.axis === "y" ? "vertical" : "horizontal")), not a second independent check — and branchhandleKeyDownon it:ArrowUp→scrollPrev(),ArrowDown→scrollNext()ArrowLeft→scrollPrev(),ArrowRight→scrollNext()scrollPrev/scrollNext, the Embla wiring, and all non-keyboard behavior are untouched.Tests (
carousel.test.tsx— this component's first tests)Mocking
embla-carousel-reactsoscrollPrev/scrollNextare spies:ArrowUp/ArrowDowncallscrollPrev/scrollNext;ArrowLeft/ArrowRightdo not scroll.ArrowLeft/ArrowRightunchanged;ArrowUp/ArrowDowndo not scroll.Verified bug-catching: reverting to the hardcoded handler fails the two vertical cases.
Validation
@loopover/ui-kit:tscbuild exit 0;prettier --checkclean;vitest run(4 tests) pass.packages/loopover-ui-kitis not in the rootcoverage.includeand isn't Codecov-gated; the acceptance bar is its own suite running green. Branched off currentmain, mergeable-clean.