构建生产就绪作品集：第2阶段 — 布局、导航与路由基础

Source: Dev.to

直到现在，前端主要以 结构和意图 的形式存在

• 文件夹已规划
• 职责已定义
• 路由已概念化

Day‑4 是这些计划开始转化为 真实用户体验 的时刻。

作为产品负责人和首席开发者，我把这一天视为：
“让我们定义用户在产品中的流动方式——以及系统如何干净利落地支持这种流动。”

为什么布局与导航值得拥有自己的阶段

在许多项目中，导航是：

• 匆忙完成
• 硬编码
• 与 UI 紧密耦合

这种做法难以扩展。

从产品角度来看：

• navigation 定义 信息架构
• layout 定义 一致性
• routing 定义 用户的心理模型

因此，我引入了一个 dedicated layout system。

引入布局层（不仅仅是组件）

首个深思熟虑的决定是创建一个 布局抽象。
这并非关于视觉——而是关于 所有权和职责。

布局层负责：

• 全局 UI 元素
• 持久化导航
• 跨路由的共享结构

这导致了三个明确的构建块：

1. NavBar
2. Footer
3. Layouts（包装器）

集中管理导航数据（像产品思考）

在编写任何 NavBar JSX 代码之前，我先问了一个简单的问题：

当导航发生变化时会怎样？
新页面、重命名的章节、链接顺序的调整——这些都是 产品决策，而不是 UI 问题。

因此，我没有在组件内部硬编码链接，而是创建了一个 唯一可信来源。

data/navLinks.js

// data/navLinks.js
export const navLinks = [
  { label: "Home",   path: "/" },
  { label: "About",  path: "/about" },
  { label: "Docs",   path: "/docs" },
  // …add more as the product evolves
];

该文件代表：

• 产品的导航结构
• 产品公开的页面
• 路由与 UI 之间的契约

通过集中管理：

• NavBar 与 Footer 保持同步
• 将来的改动变得轻而易举
• 消除了重复

它映射了真实产品中对以下内容的管理方式：

• 菜单
• 侧边栏
• 网站地图

构建 NavBar：不仅仅是链接

NavBar 通常是最显眼的组件——但也是最常被滥用的地方。
在这里，我将它视为：

• 一个品牌锚点
• 一个导航枢纽
• 一个响应式系统组件

关键设计决策

1. 品牌形象优先

• 标志 + 名称
• 可点击
• 始终返回首页

这建立了：

• 信任
• 识别度
• 连贯性

2. 桌面端和移动端同等重要

不再采用“桌面优先，移动端事后考虑”的做法，NavBar 采用了：

• 响应式逻辑
• 移动端交互模式
• 平滑过渡

这反映了 真实使用场景，而不仅仅是桌面演示。

移动端导航：为意图而设计

汉堡菜单并非随意添加——它是 经过设计 的。

关键考量：

• 明确的打开/关闭状态
• 平滑的动画
• 导航后自动关闭
• 防止意外遮挡

“即将上线”也是产品信号

你会注意到一个主题切换按钮目前还不能切换主题。
这是一种刻意的设计。

从产品角度来看：

• 它传达了路线图
• 它设定了预期
• 它避免了无声的失败

我没有隐藏未完成的功能，而是选择：

• 暴露意图
• 清晰沟通
• 保持用户体验的诚实

这是一项细微却有力的 产品领导决策。

页脚：强化结构与信任

页脚常常被忽视——但它们很重要。
此页脚有三个用途：

1. 二级导航
2. 品牌强化
3. 外部可信度（社交链接）

使用相同的 navLinks 数据：

• 确保一致性
• 防止漂移
• 强化产品的信息架构

这种复用是有意为之且具可扩展性的。

---

Layouts 组件：把一切粘合在一起的胶水

与其手动为每个页面包装，我引入了一个统一的 Layouts 组件。

职责

• 渲染持久化 UI
• 通过路由委托页面内容

使用 React Router 的 Outlet：

• 保持路由整洁
• 避免重复
• 自然支持嵌套路由

这正是 架构发挥价值 的地方。

路由：将结构转化为导航

最终，一切在路由中汇聚。

路由设置体现了：

• 干净的 URL
• 可预测的结构
• 真实场景的应用模式

每个路由：

• 映射到一个页面
• 继承布局
• 专注于内容

这种分离带来了：

• 更改布局无需触及页面
• 调整路由不会破坏 UI
• 更易于测试和调试

为什么嵌套路由是战略决策

使用共享布局配合嵌套路由并非 React 小技巧——它是一种架构承诺。

通过定义：

• 单一布局包装器
• 作为子级的页面

并通过 Outlet 渲染内容，我确保：

• 全局 UI 保持稳定
• 导航在页面之间持续存在
• 页面级组件保持专注

从产品的角度来看，这意味着：

• 体验一致
• 行为可预测
• 更易于为贡献者进行上手

Separation of Concerns: A Quiet Win

One of the most overlooked benefits of this setup is what pages do NOT know.

Pages:

• don’t care about navigation
• don’t manage layout
• focus solely on their own content

This clean separation makes the codebase easier to maintain, scale, and hand off to new team members.

Don’t import layout components

• Don’t manage global UI

They simply answer:

“What content should this route show?”

This makes the codebase:

• easier to reason about
• safer to refactor
• faster to extend

That’s not accidental — it’s intentional engineering.

---

Navigation as Data, Not UI

By treating navigation as data (navLinks.js), I unlocked multiple advantages:

• UI components stay dumb
• Product structure stays explicit
• Changes require fewer edits

From a product‑owner perspective, this is powerful because:

• Adding a new section is low‑risk
• Reordering pages doesn’t require UI rewrites
• Consistency is enforced by design

This is how real systems prevent entropy.

---

Avoiding Common Frontend Anti‑Patterns

This phase intentionally avoids several mistakes I’ve seen repeatedly in production systems:

• ❌ Hard‑coded navigation everywhere
• ❌ Layout duplicated across pages
• ❌ Routing logic scattered across files
• ❌ Mobile handled as an afterthought

Instead, this setup provides:

• A single layout owner
• A single navigation source
• Predictable routing rules
• Mobile‑first behaviour

These decisions don’t feel important on Day 4, but they save weeks later.

---

Product Thinking in Small Details

Even small choices reflect product thinking:

• “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

None of these are required for functionality.
All of them are required for experience.

That distinction matters.

---

How This Prepares the System for Scale

This foundation directly enables future work:

• Dark mode → toggle already exists
• Backend integration → pages are isolated
• Role‑based navigation → data‑driven links
• SEO & analytics → consistent layout
• Testing → predictable component boundaries

Phase‑3 isn’t about features.
It’s about creating space for features.

Source: …

Day‑4 回顾

回顾过去，Day‑4 完成了一件细微却关键的事：

它把前端从 “文件和文件夹” 转变为一个 可导航、面向用户的产品。

这正是：

• 用户开始形成意见的时刻
• 结构开始显现价值的阶段
• 技术决策变得可见的节点

从此以后，每一个新功能都将接入一个 稳定、可预测的系统。

接下来

在布局和导航就绪后，下一步的合乎逻辑的工作是：

• 构建实际章节
• 连接数据
• 塑造真实内容

第 3 阶段将继续进行，但最困难的部分——打好基础——已经完成。

结束语

优秀的前端工程并不是写 JSX 更快。
它在于做出让未来的你——以及未来的贡献者——感激的决策。

如果你正在跟着学习，完整的源码就在这里：

👉 GitHub 仓库: