Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Dashboard Sidebar Skeleton Block for React

A sales dashboard that loads in place: the labelled sidebar, stat labels and list heading stay while three figures and four open deals become data, row by row.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Show a sales dashboard while it loads, with this dashboard sidebar skeleton for React with Base UI. A hairline window with a plus mark on each corner holds a labelled sidebar from Clerestory, a sales CRM (the mark and name, seven links in two groups, Sales and Workspace, and Settings at the foot, the current one marked), a top bar with the Dashboard heading, an outline Load Button and the signed-in person, and a page of three stat cells (Pipeline, Won this month, Avg. deal) over a list of four open deals. The sidebar, the stat labels and the list heading are real from the first paint; the three figures, the person and each deal's square, title, line and amount are Skeleton bars that become the data in the same cell, row by row, when you press Load. The links say they are not wired in this demo. On a phone the sidebar becomes one scrolling row of links under the top bar. It's built from Skeleton, Avatar, Button and Guides, with a CSS entrance only. For CRMs, back offices and any dashboard with a sidebar.

FAQ

What stays local, and how do I wire it to a real query?

Nothing is fetched. The four deals are typed in DEALS, Load starts a 700 millisecond timer, and when it ends the phase becomes ready and the data swaps in; Reload goes back to the bars and in again. To wire it for real, delete the timer, the Load button and the polite line, and set data-state (loading or ready) and aria-busy on the region from your query's pending state, or use the bars as a Suspense fallback and render the real deals when they arrive. The bars are derived from the same data as the real content, so keep one component for both. The stat figures are derived from the deals, so a real app would send them with the list.

Does the window keep its height while it loads?

The window has a fixed height (h-[36rem], md:h-[46rem]) and only its page scrolls, never the window or the host page. Each bar and its data sit in one grid cell, so the larger of the two sets the cell's box, and the sidebar, the stat labels and the list heading are real in both phases. Nothing is added or removed when the data arrives, so the window is exactly as tall and every control is where it was before, during and after loading.

Why isn't this the catalog Sidebar?

A skeleton shows the loading page, not the sidebar's collapse, rail or phone sheet, so the sidebar here is plain markup: an aside holding a nav named for the product, two labelled groups and a Settings link at the foot, with the current item marked aria-current="page". Swap in the catalog Sidebar if your app needs those, and keep the page side as it is.

Is it accessible?

The region is marked busy while it loads and carries a screen-reader-only "Loading deals…", and the polite line announces what loaded once. The bars are hidden from assistive technology and the layer that isn't showing is invisible, so it is neither read nor focusable. The pulse stops when the data is in, and under reduced motion there is no pulse, no spinner and no stagger: the swap is instant. The navigation is named for the product, each group's list is named by its label, and the page is a labelled scroll region the keyboard can reach.

How does it look on a phone?

The mark and the group labels drop away and the seven links, with Settings last, scroll sideways in one row under the top bar. The three stats stack as label-and-figure rows, and the deals keep their square, title, line and amount.