Navigation blocks
Navigation blocks answer two different questions that are constantly confused: where can I go, and where am I. A block that answers the first when the reader was asking the second is why people get lost in otherwise well-built apps.
8 families, 36 blocks
- Navbars2 blocksApp shells, marketing sites, dashboards
- Tab Menu4 blocksMoving between the destinations of an app: in a sidebar or across a header
- Tabs3 blocksSwitching between peer views of one object: in a page, a panel or a field
- Breadcrumbs7 blocksDocs, file browsers, nested settings
- Pagination7 blocksTable footers, search results, any set too long for one screen
- Command Menus3 blocksPower-user navigation, actions, search
- Dropdowns7 blocksMenus, filters, account actions
- Context Menus3 blocksRight-click actions, row menus, editors
What these are for
Going somewhere is a navbar, a tab menu, a command menu. Knowing where you are is a breadcrumb trail and the selected state on whatever you used to get here. The second is not decoration: a reader who cannot see where they are cannot predict what the back button does, and an interface that fails that test feels unreliable long before anyone can say why.
Pagination sits here because it is navigation through a set rather than through an app, and it has the same requirement — the reader must be able to see where they are in the set, not only move within it. A pager that shows arrows but never a position is the same failure at a smaller scale.
Dropdowns and context menus are navigation only sometimes; often they are a list of actions. They are grouped here because they share the mechanics — an anchored overlay, keyboard traversal, a clear dismissal — and because those mechanics are where they are usually got wrong, whichever purpose they are serving.
Choosing between them
Tabs or a tab menu?
Tabs switch between peer views of one thing that is already on screen — the Overview, Activity and Settings of a single project — and stay within one page. A tab menu moves between destinations of the app and usually changes the URL. The distinction matters for the back button: leaving and returning should restore a tab menu's position, and a tab that changed no URL has nothing to restore.
Do I need breadcrumbs if I have a navbar?
Only when the structure is deeper than the navbar shows. A two-level app does not need them and gains nothing from a trail that always reads the same. A docs site, a file browser or nested settings does need them, because the navbar can show the section but not the path taken through it, and a reader arriving from a search result has no path in their head at all.
Is a command menu worth adding?
It is worth adding when your app has more destinations and actions than the navigation can show, and it is worth nothing when it does not — it will simply never be opened. It is an accelerator layered over navigation that already works, not a replacement for it, and treating it as a replacement hides everything from the readers who would never think to press a keyboard shortcut.
Dropdown or context menu?
A dropdown hangs off a control the reader can see and is discoverable by looking. A context menu appears where the pointer is, on right-click or a row's overflow button, and is discoverable only by already knowing it exists. Anything a first-time reader must find belongs in a dropdown; a context menu is for the second and third ways to do something that is already possible.
Questions
Are these blocks tied to a router?
No. They take hrefs and an active state and render links; which router resolves them is yours. That keeps the same block usable under the Next.js app router, Vue Router, or plain anchors on a static site, and it means upgrading a router does not mean re-testing your navigation components.
How does the navbar behave on a phone?
It collapses to a menu that opens over the page rather than pushing it down, with the trigger, the open state and the dismissal all keyboard-reachable. The sheet is capped to the device, not the window — a distinction that matters because a fixed overlay sized to the viewport is right on a real phone and wrong everywhere it is being previewed.
Does pagination work with infinite scroll?
They are alternatives, and the pagination blocks are for the case where a reader benefits from knowing the size of the set and being able to return to a position in it — search results, tables, anything linkable. Infinite scroll is better for feeds nobody bookmarks a position in, and worse for everything with a footer.
The other categories
All documentation
Getting started
Foundations
All components