回到列表
大家好久不见，一段时间没有写博客了，那今天就简单写写，介绍一下最近又在 HomeDash折腾了什么吧。
关于 HomeDash
接触 Next.js
在 2023 年中的时候，我开始接触 Next.js，当时的想法便是
使用 Next.js 构建属于自己的 Web 应用
在刚开始学习与折腾 Next.js 的时候，也尝试过不少的UI组件，比如
也构建了一些小的练手应用，比如公司的点餐系统与后台监控系统。
公司设备后台管理
在某一天，我想: 为什么不构建一个专属于自己的监控仪表盘呢？
HomeDash v0.0.1
Backend
监控仪表盘最核心的便是数据，因此我采用了 Go 作为数据后端，使用 gcron 作为定时任务组件，设置不同的定时任务从定义好的数据源进行数据的拉取。
就是这样简单的定时拉取，将数据通过各种 API 或者逆向 SDK 的方式收集到后端后，存储到 Redis 中，并通过 mqtt 广播出去，就完成了所需数据的处理过程。
零零散散收集到目前有大约 20 个数据源通过定时任务的方式拉取。
Frontend
对于后端顺利的开发过程来说，第一个版本的 homedash 前端构建可以算是一团糟。
当时的我对于前端框架并不熟悉，整个人完全沉浸在 React 的各种概念与组件库中，对项目架构和前端规范的了解更是一张白纸，有的只是对前端新鲜概念的一腔热血，并且当时 AI 也没有如今各种的 Claude Code 或者 Codex 这种超强 CLI 对于编程革命性的改变。
因此基本上， HomeDash v0.0.1 真的是采用了古法编程，一点点阅读文档与学习代码后纯人肉编写的。
而构建的过程中最让人抓狂也是兴奋的就是 UI 的设计与构建。
在框架的选择上，一如既往的选择了 Next.js。
虽然在 2025 年的今天看来，Next.js 因其多变的 API 与复杂的缓存模型带来的心智负担让许多开发者诟病，但是不可否认的是，Next.js 仍然是最热门，社区内容最丰富的框架之一，而且最关键的是 AI 对于 Next.js 的支持非常好，现在选择 Next.js 也仍然是不错的选择。
而在组件库的选择上，沿用了当时在公司项目中采用的字节跳动出品的前端组件库-Semi Design
当时对组件库并没有二次开发的想法，总是凭感觉选择最合适的组件一点点拼凑出仪表盘的样子。
前后大约花了一周的时间，完成了 HomeDash 第一个版本的构建。
在整个构建的过程中，都是以开源的形式进行的，竟然真的收到了一些朋友的关注。
构建后的反思
在构建完成后，首先当然对于 React 和各类组件库的用法更加熟悉了，而另一方面对于 UI 的控制与页面性能也有了许多的思考。
对于 Semi Design ，想要在原有的样式上进行修改是很困难的事情，虽然也有一些导出的属性与方法可以控制，但是还是不如直接在组件代码上修改来的直接，而这也导致了许多冗余的代码可能只是为了实现一个小样式。
而对于性能来说，Semi Design 的架构使得编译时压缩的效果并不好，许多没有用到的组件与依赖都被打包进了最后的成品中，使得 First Load JS 的大小非常大，而对于一个简单的仪表盘来说这些都大大影响了使用的感受。
最后让我弃用的原因则是 Semi Design 对于服务端渲染的支持并不太友好，支持 SSG 而对 SSR 的支持很薄弱，这就导致在使用例如 Remix 或者 Next.js 这类在运行时渲染的框架来说会出现很多问题。
因此在构建完 HomeDash v0.0.1半年后，在新旧工作短短一个月的喘息期内，我重新开始了心目中所向往的 HomeDash 的构建。
HomeDash V1
后端改造
对于后端来说，需要修改的地方并不多，最终只是重新实现了 SSE 与获取默认数据的架构，可以通过一个接口方便地以单次或者流式的方式获取最新的数据。
前端的重新构想
在开始构建时，我重新梳理了一下心中的目标：
- UI 好看
- 适配桌面端与移动端
- 性能好
- 可以在无JS的浏览器中使用
设立好这几个目标后，便是重新进行架构选择的过程。
这时一套在开源社区很火的组合让我很是兴奋。
Next.js + Tailwind CSS + Shadcn/ui
这套组合几乎完美满足了我的需求，让我完全拥有了对组件的掌控，同时这套组合在性能与服务端渲染上也相当优秀。
于是便吭哧吭哧开始了全新版本的构建。
全新的 UI 与数据获取架构
这次在 UI 的设计上，从 v0.0.1 版本中总结了许多对于设计的思考与对好设计的模仿与学习。
一切都从最快获取到有效信息的角度出发，以整体一致的 UI 带来轻松的用户体验。
全新设计的 HomeDash
在数据架构上，为了实现一打开页面就已经有数据填充而无需等待 JS 的加载与客户端数据获取的过程，采用了 Server Fetch 配合 ISR 来实现这个愉悦的使用体验。
当然你可以试试在浏览器中刷新来感受一下。
首先在定义获取数据方法时，通过设置 revalidate 参数让服务端缓存已经获取好的数据，设置为 1 的目的是启用 ISR 并保证数据的实时性。
缓存参数设置
在组件获取数据时，在服务端组件通过使用 SWRConfig 的 fallback 让服务端优先获取缓存好的数据后，再在后台更新缓存。
而在客户端，相同的，使用上面定义好的 fetch 方法绑定到 SWR 实例中，并且名称与 SWRConfig 中定义的一致，客户端在获取数据时就会先将服务端返回的数据作为填充，再进行后续的数据请求，以达到一打开页面就可以迅速查看到数据的目的。
这就是 V1 比较有意思的构建过程了，过程中还使用了最新的 View Transition API 与 Progressive Blur 来丰富页面的交互与视觉效果。
实时公交的构建
繁琐的小程序
朋友上下班的过程中，总是需要查看实时公交的信息，而每次查看都很麻烦。
- 点开微信
- 点开小程序
- 点开想要查看的公交车
经过这几步可能还看不到，还要被广告拦一层，最后车都过站了还没看到公交信息。
实时公交数据获取
既然如此，那不如在HomeDash中构建一个实时公交的页面，实时获取特定公交的信息并显示，使得打开页面就可以方便地查看到公交的信息而不用通过繁琐的步骤。
在实时公交的 API 选择上，其实有蛮多免费的选择，比如：
数据的来源不同，准确性也会有蛮大的差异。
HomeDash实时公交的API采用的是车来了的API，以获取较为准确的数据。
请求的基础地址为：
https://web.chelaile.net.cn/api/bus/line!encryptedLineDetail.action
关键是通过这 5 个参数去获取到实时的公交信息。
在成功获取到数据并解密后，通过解析其中的JSON块来获取最终的实时数据。
最终将数据整理一下，完成各个指定公交车的实时数据获取。
{
"bus_list": [
{
"busId": "343006",
"endSn": "黄埔东路（石化南路）总站",
"lines": "020-05810-0",
"price": "未知",
"reachtime": "2025-10-13 17:15",
"surplus": "10站",
"travelTime": "27分",
"distanceToWaitStn": 8154,
"speed": 0.1
},
{
"busId": "342884",
"endSn": "黄埔东路（石化南路）总站",
"lines": "020-05810-0",
"price": "未知",
"reachtime": "2025-10-13 17:05",
"surplus": "6站",
"travelTime": "17分",
"distanceToWaitStn": 5385,
"speed": 5
}
]
}前端UI构建
在UI的构建上，如何设计成一眼就可以清晰了解当前的公交状态是最核心的目的。
因此将实时公交卡片设计为两个板块，上面的是公交车的基本信息，加上最近一辆车的状态，在右侧标注公交的方向。
而在下方的公交线中划分为两块区域，在百分之70%的地方为指定的公交站点，左侧为正在前往站点的公交车信息，右侧则显示最近一班过站的信息。
这样子在查看某一路的公交车的时候，便可以清晰地快速了解线路上有用公交的信息，更好的留出时间为出行做准备。
最后搭配一些天气信息与降雨信息，上班或者出行前看一眼页面，就可以很轻松地根据天气和公交安排好出行的计划。
这就是 HomeDash 的粗略介绍和实时公交的构建过程，希望在未来继续构建出好看又好用的Feature！
谢谢你的阅读。