Radix Components

Purpose and Scope

The Radix component family is the part of the shadcn/ui catalog organized under the Radix UI documentation group. It gives teams a ready path for building accessible, composable interface patterns while still keeping the shadcn/ui model: components are copied into the application, styled with the selected shadcn style, and then owned by the project. The family is broad rather than limited to one widget category; the metadata lists primitives, layout pieces, feedback components, form controls, navigation patterns, data displays, typography, and AI-adjacent message components in the same Radix base. Sources: apps/v4/content/docs/components/radix/meta.json

Use Radix-backed components when your project needs interaction patterns that benefit from proven accessibility behavior, keyboard support, and compound-component structure, but you still want editable source in your app instead of a black-box package. Official component pages such as Accordion and Alert Dialog show the typical workflow: install with npx shadcn@latest add <component>, import named parts from @/components/ui/<component>, then compose a root, trigger, content, title, description, or item structure. Manual installation for Radix primitive-based components can include installing radix-ui, copying the generated component source, and updating import paths to match the project aliases.

The name Radix Components should not be read as a promise that every listed catalog entry wraps a Radix primitive directly. The metadata groups the docs base and style family, while individual pages describe their own dependency and usage requirements. For example, an Alert page in the official docs presents a callout component with title, description, action, variants, custom colors, and RTL guidance; an Alert Dialog page presents a modal confirmation workflow that maps more directly to a Radix primitive. Treat the family as a coherent catalog experience: consistent imports, consistent composition examples, consistent preview styling, and the same copy-into-your-code ownership model.

Relevant Source Files

• apps/v4/content/docs/components/radix/meta.json - Declares the documentation group title as Radix UI and enumerates the component pages that belong to this base, from accordion and alert-dialog through tooltip and typography.
• apps/v4/registry/bases/radix/blocks/preview/index.tsx - Implements a large Radix base preview grid made from many card examples, showing how the catalog is demonstrated as real assembled UI rather than isolated atoms.
• apps/v4/registry/bases/radix/blocks/preview-02/index.tsx - Provides a second Radix preview composition with another set of cards and the same wide-grid capture structure, reinforcing that the base is exercised through production-like blocks.

Catalog Organization

The Radix family metadata is the most direct source for the family boundary. It declares title as Radix UI and lists pages such as accordion, alert, alert-dialog, avatar, button, calendar, command, dialog, dropdown-menu, form, navigation-menu, popover, select, sheet, sidebar, sonner, tabs, toast, and tooltip. That list matters because users do not choose a base only for one component; they choose a component system whose examples, documentation routes, style previews, and registry output work together. Sources: apps/v4/content/docs/components/radix/meta.json

A useful way to read the list is by capability. Disclosure and overlay patterns include accordion, collapsible, dialog, drawer, hover-card, popover, sheet, and tooltip. Navigation and command surfaces include breadcrumb, command, context-menu, dropdown-menu, menubar, navigation-menu, pagination, and sidebar. Form and input surfaces include checkbox, combobox, field, form, input, input-group, input-otp, label, native-select, radio-group, select, slider, switch, textarea, toggle, and toggle-group. Content and feedback surfaces include alert, alert-dialog, badge, card, empty, progress, skeleton, sonner, spinner, and toast.

That breadth is why the Radix family is often the default choice for application teams starting from the official docs catalog. You can add a Button, then add Dialog, then compose Alert Dialog with Button, then introduce Form or Select without switching documentation models. The official snippets use the same install and usage framing across pages: CLI-first installation, a manual copy path when needed, imports from @/components/ui/..., and composition diagrams that name each exported part. The result is a catalog that teaches both the component API and the component ownership model.

System-to-Code Mapping

The preview entrypoints show how the Radix base is validated visually through assembled blocks. PreviewExample imports card components such as ActivateAgentDialog, AnalyticsCard, AnomalyAlert, BookAppointment, FeedbackForm, FileUpload, InviteTeam, Invoice, ReportBug, ShippingAddress, Shortcuts, SkeletonLoading, StyleOverview, TypographySpecimen, UIElements, and chart or activity cards. The default export renders an overflow-controlled container and a seven-column grid with data-slot="capture-target", which gives the preview and capture pipeline a stable target for screenshots or rendered examples. Sources: apps/v4/registry/bases/radix/blocks/preview/index.tsx

The second preview entrypoint follows the same idea with a different product vocabulary. It imports cards such as AccountAccess, CardOverview, ClaimableBalance, ContributionHistory, Faq, FrontDoor, NotificationSettings, Payments, Preferences, RecentTransactions, ReleaseCatalog, SavingsProgress, SidebarNav, SocialLinks, TransferFunds, and UpcomingPayments. Its exported component also renders an overflow-safe, wide grid with style-specific width adjustments and data-slot="capture-target". This repeated structure is a signal that Radix components are evaluated as a system of reusable patterns across many realistic surfaces, not just as standalone examples. Sources: apps/v4/registry/bases/radix/blocks/preview-02/index.tsx

The preview layout also shows an important implementation constraint: component families must survive dense, mixed-content compositions. The grid uses muted and dark background classes, spacing variables such as --gap, responsive width changes, and style-specific overrides for style-lyra and style-mira. Several columns use content-visibility:auto and contain-intrinsic-size, which suggests the preview is designed to remain performant while presenting many examples at once. When you customize Radix components locally, test them in similarly mixed contexts, because spacing, dark mode, responsive behavior, and nested interactive components are where design-system regressions usually appear.

Installation and Usage Pattern

For most users, the CLI is the safest starting point. Official Radix component docs show commands such as:

npx shadcn@latest add accordion
npx shadcn@latest add alert-dialog
npx shadcn@latest add alert

After adding a component, import its public parts from your configured UI alias. Accordion, for example, uses named exports such as Accordion, AccordionContent, AccordionItem, and AccordionTrigger. Alert Dialog uses a larger set including AlertDialog, AlertDialogTrigger, AlertDialogContent, AlertDialogHeader, AlertDialogTitle, AlertDialogDescription, AlertDialogFooter, AlertDialogCancel, and AlertDialogAction. These names are intentionally descriptive: they make composition readable in application code and keep accessibility roles close to the structure of the component.

Manual installation follows the same conceptual sequence but makes the ownership boundary explicit. Install required dependencies when a page calls for them, copy the component implementation into the project, and update import paths to match the app. In practice, that means aligning @/components, @/lib/utils, and any workspace aliases with the project’s components.json and TypeScript path configuration. The Radix family works best when those aliases are stable, because every component example assumes imports from the local component library rather than a central external package.

Choosing Radix Versus Other Component Families

Choose the Radix family when accessibility-centered primitives, compound composition, and predictable interaction behavior are more important than minimizing dependencies or writing every interaction from scratch. Dialogs, dropdown menus, select controls, popovers, tabs, accordions, and menu-like surfaces all have subtle keyboard and focus-management requirements. The official docs link many of these pages to Radix primitive documentation and API references, which gives developers a second layer of behavioral documentation underneath the shadcn/ui wrapper and styling conventions.

Choose it also when you want a large catalog with consistent examples. The metadata list includes both foundational pieces and higher-level application patterns, while the preview blocks demonstrate dashboards, forms, upload flows, settings panels, financial cards, and empty states. That combination supports incremental adoption: start with small pieces like Button, Alert, Badge, or Skeleton, then adopt interaction-heavy parts like Dialog, Dropdown Menu, Command, Select, or Tabs as the application grows. Sources: apps/v4/content/docs/components/radix/meta.json, apps/v4/registry/bases/radix/blocks/preview/index.tsx, apps/v4/registry/bases/radix/blocks/preview-02/index.tsx

A different family may be appropriate when your team has a hard requirement for another primitive layer, a design-system constraint that conflicts with Radix behavior, or a project policy that avoids the dependencies used by a specific component. Because shadcn/ui copies source into your project, choosing Radix is not an irreversible platform decision; it is a starting point for implementation. The important commitment is to keep the copied components understandable, preserve their accessibility contracts during customization, and test them in the same composed contexts where users encounter them.

Compact Reference

• Family title in docs metadata: Radix UI.
• Source family path: apps/v4/content/docs/components/radix/meta.json.
• Example add command shape: npx shadcn@latest add <component-name>.
• Common import shape: @/components/ui/<component-name>.
• Manual workflow shape: install dependencies when required, copy the component source, then update import paths.
• Preview entrypoints: PreviewExample and Preview02Example.
• Preview capture marker: data-slot="capture-target".
• Representative catalog pages: accordion, alert, alert-dialog, avatar, button, calendar, command, dialog, dropdown-menu, form, popover, select, sheet, sidebar, sonner, tabs, toast, tooltip.

Next Steps

Start with the individual component page for the pattern you need, then add it through the CLI before customizing. If you are building a new app surface, preview the component inside realistic layouts rather than in isolation, because the Radix base is designed and demonstrated through dense composed blocks. For implementation details that affect installed output, read the CLI and components.json pages next. For nearby catalog choices, compare the ARIA Components and Base Components pages so your team intentionally chooses the primitive model and documentation family that fit the project.