kargulstudio/calender-app-design

这是一个用来评估的设计原型，不是可以拿来给团队排班或记录休假的工具。想找日历与请假管理界面的可交互参考，值得打开看看；想存真实团队数据，不合适。

解决什么问题

团队做人事工作台，通常从 Figma 稿开始，再把日历网格、事件弹层、请假申请弹窗用代码重新搭一遍，才能测出拖拽跨天、请假按工作日计算这类交互是否顺手。在此之前，设计决策只能停留在静态稿上。这个项目把「Dashboard – calendar」的设计落成了可运行的网页：Time off 页面按设计稿还原，侧边栏其他页面沿用同一套视觉语言。起点因此从「审阅稿子」变成「点开原型」，但产物本身的定位没有变。

有什么不同

它的辨识度主要在于 README 声称已经实现的前端交互细节。日历有周、日、月三种视图，支持在空白处拖拽新建、拖动事件跨天移动、拖底边调整时长、重叠事件并排排布，还有带公共节假日的全天栏和实时当前时间线。休假模块的申请弹窗会跳过周末和节假日计算工作日，并显示申请后的余额；请求表格支持搜索、筛选、排序、查看详情、编辑、取消、删除，另有经理批准或拒绝的预览。此外还有 ⌘K 搜索、键盘快捷键和深色模式。

实现方式刻意保持简单：没有后端，状态由 Zustand 的 persist 中间件写入 localStorage。这让原型方便做静态演示、也方便重置，但数据模型、权限模型和服务端校验都没有被验证。README 明确说明种子数据还原的是设计稿里 2026 年 11 月 8–14 日那一周，并提示可用 Settings → Data → Reset demo data 回到初始设计状态。批准/拒绝界面应视为 UI 预览，而不是可用的审批流程。

谁值得试

最合适的是正在做内部排班或请假管理界面的前端开发者和设计师：看在线 demo 可以直接参考拖拽行为、重叠布局和键盘导航的具体做法。想把它当作自己视觉语言的起步骨架的团队也合适，README 说明了 Figma 变量如何映射到 Tailwind 设计 token，并把 UI 基础组件、外壳、日历和休假组件分开组织。

反过来，需要给团队真正记录日历或休假的人不适合。数据只存在浏览器里，人与人之间不共享，没有账号，也没有持久记录。想研究完整请假规则的人也会觉得这里很薄：README 描述的是工作日计数和额度加减，不是一套请假政策引擎。

使用条件与边界

启动是标准 Next.js 流程：安装依赖、跑开发服务器、打开 localhost，具体见项目说明。技术栈绑在当前版本上——Next.js 16、React 19、Tailwind CSS v4，以及基于 Radix 的 shadcn/ui——想搬进旧项目就要预留改造工作。项目没有数据库、鉴权和 API 层，README 也没有给出补充这些内容的路径，后端相关的事全由使用者自己决定。

长期边界在于状态范围。localStorage 能在同一浏览器刷新后保留，但它不是共享或权威的数据源，跨设备、多人协作超出原型提供的能力。重置按钮能让 demo 回到设计状态，但这只是原型的便利，不是数据管理方案。打算复用时，最好先分清哪些部分只当视觉参考、哪些准备配真实后端重写。

HotRepo 点评

HotRepo 唯一有记录的观察是 2026-10-27 的 TypeScript 新项目榜 #11，累计 113 星；这不是总榜排名，也不是单日新增。仓库创建于 2026-10-26，可追踪证据只覆盖一天，无法判断关注度能否持续。因此更稳妥的判断是把它当设计参考：打开在线 demo 和项目说明，看这些交互细节是否对口；把组件搬进自己代码库前，先确认 MIT 许可证，而不是拿它当生产日历评估。