Moving Through an App

Navigation is a rendering of the information architecture, not a layer designed on top of it. Default posture: the flattest tree the content permits, exactly one primary index, and the URL as the single source of truth for where the user is and what they are looking at. Every level, every nav region, and every menu you add is paid for by every user on every visit — so add one only when the content forces it, and delete one the moment a flatter shape still answers "where am I, and what else is there?". This skill owns the movement graph and never names a container: which container a single flow gets once it has a place in that graph — modal, drawer, sheet, popover, inline expand, or full page — belongs to modal-or-page. Arrangement inside one page is layout; the timing of the movement between destinations is transitions.

Read the router before writing a line of nav. Next App Router, React Router, TanStack Router, SvelteKit, Nuxt and Expo Router each have their own model of nested layouts, route params, search params, scroll restoration and history. Navigation state lives in the router the project already has (<Link>, useSearchParams, loaders) — never in a parallel useState store shadowing the URL, which is how back buttons start lying. If the project already ships a nav primitive from its design system, extend that one; a second sidebar component is a second source of truth about the app's shape.

Quick Reference

Open it once you know which archetype you are building; it saves re-deriving the same skeleton and keeps two apps in one product from disagreeing about their own shape.

Decision: which nav shape