fix(web): usable mobile layout and canonical YuTheme alignment #43
No reviewers
Labels
No labels
bug
dependencies
documentation
duplicate
enhancement
good first issue
help wanted
invalid
javascript
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
isyuricunha/yue-discord-bot!43
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/panel-mobile-and-theme"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Two panel problems reported by Yuri: mobile is unusable, and the theme does not match the ecosystem. Both measured in a real browser at 375/768/1440 before and after, authenticated against the running API.
1. Mobile was broken because the shell had no mobile layout
The 260px sidebar rendered at every viewport width. At 375px it took 69% of the screen, squeezed the main column to 115px, and pushed content out to
right: 464px. Critically,document.scrollWidthstayed at 375, so that overflow was clipped and unreachable, not scrollable./dashboard/guild/:id/members/guild/:id/overviewBelow
lgthe sidebar is now an off-canvas drawer:prefers-reduced-motionrespectedDesktop is untouched: verified at 1440px the sidebar is still in normal flow at 260px, main is 1180px, and the menu button is absent. Tablet (768px) uses the drawer.
Touch targets: 12 below the 44px minimum, now 1 (an unrelated error-state button). Nav links and topbar actions are 44px on mobile and keep the compact 36px rail on desktop.
Zoom 200%: no horizontal overflow.
Note on a subtle bug hit while implementing
The drawer initially would not slide despite correct state. Cause:
cn()uses tailwind-merge, and the dynamic width class was merged after the mobile width/transform utilities, silently dropping them. Fixed by ordering the responsive desktop width before the mobile transform state.2. Theme drift from canonical YuTheme
The panel defined its own palette instead of the canonical tokens in the website repo (
packages/ui/styles/preset.css):#000000pure black#1a1813warm brown-black#0a0a0a#1b1913#e0e0e0grey#f4f1e8ivory#c98218orange#d6a84fgold#64d2ffcyan#8bc34a#31d158#c7a45d#bf5af2purplergba(255,255,255,...)coldrgba(214,204,176,...)warmThis was exactly the "dark mode is not pure black" pitfall from the design system: the panel read cold while the rest of the ecosystem reads warm. Both token layers were aligned (the
--yu-*hex tokens and the--yu-rgb-*triples Tailwind consumes), so no component markup changed. Verified in-browser: computed body background isrgb(26, 24, 19)and textrgb(244, 241, 232).Validation
type-check,lint,teston@yuebot/web: all green, 182 tests passing (17 files).aria-controls/aria-expanded, click handler).Also
Adds an optional
VITE_DEV_API_PROXYdev proxy so local development can reach a running API on the same origin without relaxing the API's CORS allowlist or the dev CSPconnect-src 'self'.