UI issues + notes

Situation

The stack is Next.js + TypeScript + Tailwind + Radix

• Primitives (Dialog, DropdownMenu, etc.) are used ad hoc across apps/packages.
• Styling drifts: similar patterns reimplemented with different class strings, spacing, and state styles.
• Props APIs differ per screen: one team passes className, another wraps Radix with local variants; discriminated unions and slot patterns are inconsistent.
• Design tokens (radius, focus rings, destructive colors) are implied by Tailwind classes, not centralized in a small set of components.

Task

Introduce shadcn/ui not as “another UI library,” but as a codified component boundary: copy-in components that wrap Radix + Tailwind with stable props, variants, and composition slots—aligned with your monorepo and design system.

Success looks like: fewer one-off wrappers, predictable APIs, faster feature work, safer refactors, and a single place to evolve tokens and interaction patterns.

Action

1. Initialize shadcn in the Next app(s) that own UI (CLI sets components.json, aliases, Tailwind theme extensions).
2. Replace scattered Radix usage incrementally: start with Button, Input, Dialog, DropdownMenu, Form (often paired with react-hook-form + zod).
3. Lock variants with class-variance-authority (CVA) or tailwind-variants so visual states are data (variant, size) not string soup.
4. Treat components/ui/* as internal SDK: apps import from @/components/ui/... (or package path), not from Radix directly except inside those files.

Result

• Type safety: Variant props become finite unions; asChild + Slot patterns are typed once. Form field errors bind to schema types end-to-end (zod → inferred types → field components).