Update October 2025

We're excited to announce that we updated our Figma kit to match the newest shadcn/ui release. This update introduces new components like Button Group, Field, Input Group, Item, Kbd, and Spinner—plus fresh Sign up and OTP blocks. We’ve also polished existing components, added new Button icon sizes (icon-sm, icon-lg), swapped loading states to Spinner, and unified forms with the new Field component.

Figma

New components

Be sure to visit the component pages Playground in our Figma kit for new examples that show how to build different variants.

• Added Button Group
• Added Empty
• Added Field
• Added Input Group
• Added Item
• Added Kbd
• Added Spinner
• Added “Sign up” and “OTP” blocks to the Blocks (Official) page
• Added Checkbox Group
• Added Switch Group

Component updates

• Button: added new icon size variants — icon-sm and icon-lg
• Button: replaced Loading icon with the Spinner component for loading state
• Input, Checkbox, Radio Group, Date Picker, Switch, Slider, and Time Picker: updated for compatibility with the new Field component
• Tooltip: added a Kbd instance
• Blocks (Official) forms: migrated to the new Field component
• ToggleGroup: general improvements
• Table: general improvements
• Data Table: general improvements
• Avatar: Added Avatar / Form Field component

Variables updates

• Added a new stroke-width variables group to the “1. Tailwind CSS” collection (prevents Figma from altering icon stroke width when swapping icon instances)
• Added a new “bg-primary\5 dark:bg-primary\10” variable to the Custom group in the “3. Mode” collection (used by Kbd component, Background=Primary variant)

Questions and answers

Can I update my existing UI kit to include the new components and changes?

Please see our guide in the documentation.

Why the Form component is still in Figma but it's no longer available in shadcn/ui?

We'll be deleting Form page in the next Figma kit update (Form is replaced by the Field component).

Are the Pro Blocks (React) updated to support the new components?

Not yet. We plan to update Pro Blocks code in an upcoming update.

Deep dive into the new October 2025 primitives in shadcn/ui

The October 2025 update adds seven new primitives: Spinner, Kbd, Button Group, Input Group, Field, Item, and Empty; each made to handle those small, repeated bits of UI we end up rewriting in every project.

If you've ever copied code for a simple loading spinner or spent time aligning buttons, you'll know the pain these new components aim to fix. Let's go through them one by one.

The big idea: framework-agnostic, pattern-first

These primitives are about predictable markup, roles, and class hooks. No hidden state. No tight coupling. You can drop them into React, Vue, Svelte, Solid, or plain HTML and wire them with whatever state tool you like. Your theme tokens flow through, your icons plug in, and your accessibility rules stay intact. That is how they reduce repetition: the pattern is stable, the binding is up to you.

Spinner

What it is: A consistent way to show loading, from tiny inline hints to full page waits.

Why it matters: Teams often ship five different spinners with five sizes and three colors. A shared Spinner gives you one design language for progress across buttons, tables, modals, and pages.

Where it shines:

• Inline feedback inside buttons and inputs
• Section loading for cards, lists, and tabs
• Page or route transitions with an overlay

Good habits: Pair it with clear copy like "Saving" or "Loading results." Mark busy regions so screen readers know an area is updating. Keep motion subtle to avoid visual noise.

Kbd

What it is: A small component for keyboard keys and shortcuts. Think Esc, ⌘K, Ctrl + S.

Why it matters: Shortcuts appear in docs, menus, tooltips, banners, and onboarding. Kbd keeps them readable and consistent, with spacing and typography that match the rest of your UI.

What you can do now:

• Show global search (⌘K) in headers and command menus
• Add inline help like "Press Esc to close" in dialogs
• Document power shortcuts in tooltips and empty states

Accessibility tip: Localize labels for platform keys. On Windows, show Ctrl. On macOS, show ⌘.

Button Group

What it is: A wrapper that keeps a row of buttons tight, aligned, and tidy.

Why it matters: Toolbars and segmented controls often have gaps, double borders, or odd radii. Button Group merges edges so the group reads as one control.

Use cases:

• Toggle between List / Grid / Table
• Step through pages with Prev / Next
• Cluster-related actions like Edit / Duplicate / Archive

Team benefit: Designers can hand off one pattern. Developers stop hand-tuning borders on every screen.

Input Group

What it is: A flexible input wrapper for prefixes, suffixes, icons, and small actions.

Why it matters: Most apps repeat the same structure around inputs. Search icons. Clear buttons. Currency and unit labels. Input Group standardizes the chrome, so you do not rebuild it each time.

Patterns it unlocks:

• Search with a leading icon and a trailing "Clear"
• Amount fields like $ 1,250.00 or 12 kg
• Date inputs with a calendar button
• Token fields with addon chips or hints

Design note: Because it is a wrapper, you keep your existing inputs. The group handles spacing and alignment.

Field

What it is: The form glue. It ties together a label, the control, a hint, and an error. It wires ids and ARIA so assistive tech reads the right thing.

Why it matters: Form markup gets messy fast. Field locks in a good structure. You get consistent labels, optional hints, and clear error messaging without custom wiring every time.

Where to use it:

• Any labeled input: text, select, date, file
• Complex fields like phone numbers with country codes or passwords with a strength meter
• Reusable form rows in settings pages

Accessibility checklist: Each field should have one label, an optional hint, and an optional error. These link to the input so screen readers announce them in order.

Item

What it is: A simple row primitive for selectable lists. Think menu items, command items, dropdown options, and settings rows.

Why it matters: Lists often need the same states again and again. Hover. Focus. Selected. Disabled. The item gives you one reliable row that supports those states without you inventing a new pattern.

What you can do now:

• Build menu and command lists that feel consistent
• Attach left content like icons or avatars and right content like badges or shortcuts
• Style selected and disabled rows the same way everywhere

Styling tip: Drive states with data attributes so your styles remain readable and portable.

Empty

What it is: A friendly "nothing here yet" block that sets context and provides a next step.

Why it matters: Blank screens confuse users. Empty gives them a short message, a small visual, and one clear action.

Great uses:

• No search results with a suggestion to broaden filters
• New accounts with a prompt to create a first project
• Sections like notifications or favorites when they are truly empty

Tone advice: Keep the title short, the description helpful, and offer a single primary action. Optional secondary links can sit below.

How do these seven cut repetition

• One pattern, many places. Field fixes form structure across the app.
• Shared Chrome. Button Group and Input Group handle borders, spacing, and alignment once.
• State without noise. Item standardizes hover, focus, selected, and disabled.
• Friendly gaps. Empty gives all blank states a voice and a path forward.
• Consistent micro-feedback. Spinner and Kbd improve the details users feel every day.

The payoff is less custom markup, fewer throwaway wrappers, and a cleaner design system that feels the same from page to page.

Why "framework-agnostic" helps your team

• Portable patterns. The same structure works in any stack. If you switch frameworks, you keep the building blocks and only rebind state.
• Token-first styling. Colors, radii, and spacing flow from your theme. No hidden styles to fight.
• Composable by default. Each primitive focuses on one job. You compose them to fit your product, not the other way around.

Practical ways to roll them out

• Start with pain. Replace your noisiest custom pieces first. For most teams, that is the Input Group and Field.
• Set tokens early. Make sure your color, radius, and spacing scales are in place. Every primitive will pick them up.
• Agree on copy. Spinner labels, Empty titles, and Field hints should follow the same voice.
• Document examples. Show at least one good and one bad pattern for each primitive in your internal docs.
• Adopt globally. Use the same Empty and Item styles across features so the app feels coherent.

Accessibility notes to keep handy

• Spinner: Announce live updates and avoid relying on color alone.
• Kbd: Use readable contrast and localize platform keys.
• Field: Connect labels and messages to the control so the reading order makes sense.
• Item: Reflect selection and disabled states for both visuals and assistive tech.
• Empty: Do not trap focus. Treat it like content, not a dialog.
• Groups: If a group needs context, add a clear group label.

Final takeaway

These primitives are small, but they fix problems you bump into every week:

• Loading that looks the same everywhere
• Shortcuts that read well
• Button rows that sit cleanly
• Inputs with addons that do not break the layout
• Forms that speak clearly
• List rows with predictable states
• Blank screens that guide users

Adopt them where you feel the most friction. You will write less code, ship faster, and your product will feel more consistent without a heavy rewrite.