Choosing a library for an admin interface is a different problem from choosing one for a landing page, and the usual recommendations answer the wrong question. A dashboard is not short of visual ideas. It is short of the four parts that carry real data: a shell, a table, a chart set and a form system, all agreeing with each other about spacing, focus and error states.
Here is what each source actually gives you.
The four parts
The shell. Sidebar, header, content area, and the collapse behaviour that turns it into a phone layout. Sidebar by Manu Arora, Dashboard with Collapsible Sidebar by Sonu, Sidebar Component by jshguo and Sidebar by Andrew Luo are the shapes, and the sidebar guide covers the states a real one has to hold.
The table. The part that decides whether the product is usable: sorting, filtering, column visibility, pagination or virtualisation, and row selection that survives a page change. The data table guide is the longer version.
The charts. Covered in the chart guide. The short version is that most dashboard "charts" are a number with a shape behind it, and only some of them need a charting library.
The forms. Settings, filters, creation flows. Validation, error summaries and the states in between.
What each source covers
| Source | Shell | Table | Charts | Forms |
|---|---|---|---|---|
| shadcn/ui | Sidebar block | TanStack Table wiring | Recharts wrapper | Primitives plus RHF |
| A general registry | Assembled variants | Variants of the above | Variants | Variants |
| Tremor | No | Basic | The strongest set here | Minimal |
| A packaged library | Yes | Yes | Usually | Yes |
| 21st | Community shells | Community tables | KPI cards and panels | Community pieces |
The row that matters most is the last column of the first row: shadcn/ui plus TanStack Table plus React Hook Form covers three of the four parts with the parts everyone else builds on anyway.
The recommendation, stated plainly
For most teams building an admin interface today: shadcn/ui for the primitives and the sidebar block, TanStack Table for the data grid, the shadcn chart wrapper for anything with an axis, and React Hook Form with a schema validator for forms. Then one general registry for variants, so the second and third screens do not each invent their own spacing.
That is not exciting advice and it is the setup that survives the second year, because every piece of it is code in your repository rather than an API you are negotiating with.
Reach for a packaged library instead when the team is large enough that consistency has to be enforced rather than agreed, and when nobody will be asked to make the admin panel look distinctive.
The three things that make a dashboard good, which no library provides
Hierarchy. One headline number, then its trend, then the breakdown. A reader should be able to answer whether things are fine before asking why.
Density that matches the task. Cards while browsing, a dense table while scanning for one row. A card grid at two hundred items is a table with the alignment removed.
Empty and loading states designed with the same care as the populated ones. A dashboard is empty on day one for every new account, and that is the screen that decides whether they come back.
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a dashboard shell, get the previews inline, and let the agent write the file.
Frequently asked
- What is the best component library for an admin dashboard?
- For most teams: shadcn/ui for primitives and the sidebar block, TanStack Table for the grid, the shadcn chart wrapper for anything with an axis, and React Hook Form with a schema validator for forms. It is unexciting advice and it survives the second year, because every piece is code in your repository rather than an API you negotiate with.
- When is a packaged library the better choice for a dashboard?
- When the team is large enough that consistency has to be enforced rather than agreed, and when nobody will be asked to make the admin panel look distinctive. You trade the ability to change anything for the ability to not have to, which is a good trade at that size.
- What are the four parts of a dashboard?
- A shell with a sidebar and its collapse behaviour, a table with sorting, filtering and selection that survives pagination, a chart set, and a form system. The parts matter less individually than whether they agree with each other about spacing, focus and error states.
- What makes a dashboard good beyond the components?
- Hierarchy, so a reader can tell whether things are fine before asking why. Density that matches the task, since a card grid at two hundred items is a table with the alignment removed. And empty states designed with the same care as populated ones, because every new account sees the empty one first.