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 hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - 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