Tools: Building a Production-Ready Portfolio: Phase-2 — Layout, Navigation & Routing Foundations

Why Layout & Navigation Deserve Their Own Phase ## Introducing a Layout Layer (Not Just Components) ## Centralising Navigation Data (Thinking Like a Product) ## data/navLinks.js ## Building the NavBar: More Than Just Links ## Key Design Decisions ## 1. Brand Identity Comes First ## 2. Desktop and Mobile Are First-Class Citizens ## Mobile Navigation: Designing for Intent ## “Coming Soon” Is Also a Product Signal ## Footer: Reinforcing Structure & Trust ## Layouts Component: The Glue That Holds Everything Together ## Routing: Turning Structure Into Navigation ## Why Nested Routing Is a Strategic Decision ## Separation of Concerns: A Quiet Win ## Navigation as Data, Not UI ## Avoiding Common Frontend Anti-Patterns ## ❌ Hardcoded navigation everywhere ## ❌ Layout duplicated across pages ## ❌ Routing logic scattered across files ## ❌ Mobile handled as an afterthought ## Product Thinking in Small Details ## How This Prepares the System for Scale ## Day-4 in Retrospect ## What’s Next ## Closing Thought Until now, the frontend existed mostly as structure and intent: Day-4 is where those plans started turning into real user experience. As a product owner and lead developer, I treated this day as: “Let’s define how users move through the product — and how the system supports that movement cleanly.” In many projects, navigation is: That approach doesn’t scale. From a product perspective: So instead of sprinkling headers and footers everywhere, I introduced a dedicated layout system. The first deliberate decision was creating a layout abstraction. This was not about visuals — it was about ownership and responsibility. The layout layer is responsible for: That led to three clear building blocks: Before writing a single line of NavBar JSX, I asked a simple question: What happens when navigation changes? New pages, renamed sections, reordered links — these are product decisions, not UI problems. So instead of hardcoding links inside components, I created a single source of truth. This file represents: By centralising this: This mirrors how real products manage: The NavBar is often the most visible component — but also one of the most abused. Here, I treated it as: The NavBar was built with: This reflects real-world usage, not just desktop demos. The hamburger menu was not just added — it was designed. This is where UI meets UX responsibility. You’ll notice a theme toggle button that doesn’t yet switch themes. This was intentional. From a product perspective: Instead of hiding incomplete features, I chose to: This is a subtle but powerful product leadership decision. Footers are often ignored — but they matter. The footer here serves three purposes: Using the same navLinks data: This reuse is intentional and scalable. Instead of wrapping every page manually, I introduced a single Layouts component. Using React Router’s Outlet: This is the point where architecture pays off. Finally, everything comes together in routing. The routing setup reflects: This separation allows: Using a shared layout with nested routes is not a React trick — it’s an architectural commitment. From a product lens, this means: One of the most overlooked benefits of this setup is what pages do NOT know. “What content should this route show?” This makes the codebase: That’s not accidental — it’s intentional engineering. By treating navigation as data (navLinks.js), I unlocked multiple advantages: From a product-owner perspective, this is powerful because: This is how real systems prevent entropy. This phase intentionally avoids several mistakes I’ve seen repeatedly in production systems: Instead, this setup provides: These decisions don’t feel important on Day 4, but they save weeks later. Even small choices reflect product thinking: None of these are required for functionality. All of them are required for experience. That distinction matters. This foundation directly enables future work: Phase-3 isn’t about features. It’s about creating space for features. Looking back, Day-4 achieved something subtle but critical: It transformed the frontend from “files and folders” into a navigable, user-facing product. And from here on, every new feature plugs into a stable, predictable system. With layout and navigation in place, the next logical step is: Phase-3 continues, but the hardest part — getting the foundation right — is now done. Good frontend engineering isn’t about writing JSX faster. It’s about making decisions that future you — and future contributors — will thank you for. If you’re following along, the complete source lives here: 👉 GitHub Repository: https://github.com/imsushant12/sushantgaurav-portfolio Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. as well , this person and/or - folders were planned - responsibilities were defined - routing was conceptual - tightly coupled to UI - navigation defines information architecture - layout defines consistency - routing defines mental models for users - global UI elements - persistent navigation - shared structure across routes - Layouts (wrapper) - the product’s navigation structure - the pages the product exposes - the contract between routing and UI - NavBar and Footer stay in sync - future changes are trivial - duplication is eliminated - a brand anchor - a navigation hub - a responsive system component - Logo + name - Always returns to home - recognition - desktop first - mobile as an afterthought - responsive logic - mobile interaction patterns - smooth transitions - clear open/close state - smooth animations - auto-close on navigation - no accidental overlays - it signals roadmap - it sets expectation - it avoids silent failure - expose intent - communicate clearly - keep UX honest - Secondary navigation - Brand reinforcement - External credibility (social links) - ensures consistency - prevents drift - reinforces the product’s information architecture - render persistent UI - delegate page content via routing - keeps routes clean - avoids duplication - supports nested routing naturally - predictable structure - real-world app patterns - maps to a page - inherits layout - stays focused on content - layout changes without touching pages - routing changes without breaking UI - easier testing and debugging - a single layout wrapper - pages as children - content rendered via Outlet - global UI remains stable - navigation persists across pages - page-level components stay focused - consistent experience - predictable behaviour - easier onboarding for contributors - don’t care about navigation - don’t import layout components - don’t manage global UI - easier to reason about - safer to refactor - faster to extend - UI components stay dumb - product structure stays explicit - changes require fewer edits - adding a new section is low-risk - reordering pages doesn’t require UI rewrites - consistency is enforced by design - a single layout owner - a single navigation source - predictable routing rules - mobile-first behaviour - “Coming soon” tooltip instead of broken buttons - animated feedback instead of silent state changes - brand presence in both header and footer - social links for credibility and trust - Dark mode → toggle already exists - Backend integration → pages are isolated - Role-based navigation → data-driven links - SEO & analytics → consistent layout - Testing → predictable component boundaries - users start forming opinions - structure starts paying off - technical decisions become visible - building actual sections - connecting data - shaping real content