Best dashboard blocks 2026: 43 verified sections

A dashboard block is almost always a shell with a sidebar, not a dashboard. The catalogue counts 43 from 9 registries, measured on 1 November 2026 on /api/blocks/category/dashboard, and the top five rows are shells of six to eleven files.

Why the shell is the delicate part

The sidebar looks like a visual detail and is really shared state. If its open state lives in a cookie or in localStorage, the first server render does not know the preference and the client draws another layout: the result is a visible jump at hydration, or a mismatch error when the component reads the value during render. The second problem is scrolling: two containers with nested scrolling, the sidebar and the content, lose the wheel on desktop and bounce on mobile.

The third is the keyboard. A shortcut such as command plus B to close the sidebar can collide with the browser or with another application shortcut. The fourth is depth: eleven files mean the block includes a provider, a context and child components, and every change to the provider touches everything beneath it.

What to read before adopting the shell

• Whether the sidebar state comes from the server or the browser: in the second case you need a first-render strategy.
• How many containers scroll on their own, and whether the main content has exactly one.
• Whether the sidebar has a mobile sheet or drawer, because the desktop version does not fit at 360 pixels.
• Whether keyboard shortcuts are declared and whether they can be turned off.
• The publisher licence, which on complete shells is the first item to verify.

An eleven-file block is not automatically better. It hands you an architecture already thought through and asks you to accept it: replace the provider with your own and you are rewriting the part the block had solved. Do the sums on how many internal pages share the same shell, not on the file count.

The limitation the catalogue does not cover

None of the 43 blocks handles authorisation or per-route data loading. There is no permission check in the sidebar, no suspense boundary for the content, no error state when a page's API fails. The second limitation is licensing: the shell can be free while the bundled icons are not.

The rule that saves the shell

If the sidebar collapses per user, keep the block's provider and replace only the page content: two implementations of the same sidebar is the fastest route to two bugs. If you need a different sidebar, start from a primitive and write it, because adapting an eleven-file shell costs more than building it. Either way decide where the state lives first, and decide that the server must be able to draw the first frame.

The alternative is a page with no shared shell and top navigation. For applications with three or four screens it is the cheaper choice: no shared state, no hydration jump, and on mobile top navigation fits without a sheet. The sidebar pays off when destinations exceed seven and must stay visible while you work.

Loading is the other half of the work. A complete shell draws the sidebar and header at once, then leaves an empty rectangle where the numbers will land: when the content drops in without a placeholder of the same height, the page moves twice. Check whether the block ships loading skeletons for cards and tables, and how many are needed for the real case. A shell without skeletons is half a shell.

curl "https://ui.eneawork.it/api/blocks/category/dashboard?limit=10"

The shells are in /blocks/category/dashboard, sidebars in /components/cat/sidebar and icons in /icons. For the data side read a TanStack table and what a UI library weighs; the comparison between a complete block and composing from primitives is in copy-paste or headless.