feat: prioritize upcoming alarm context#7
Conversation
- 调整时间字体大小从68到60 - 添加重复规则显示 - 调整标签字体大小和间距
- 为闹钟项添加卡片样式(白色背景、圆角、阴影) - 将标签和重复规则放在同一行,节省垂直空间 - 编辑模式删除按钮添加确认对话框 - 统一AlarmEditView设置卡片行高 - 为展开/折叠的“稍后提醒时长”添加动画过渡 - 为TabView选中状态添加更明显的视觉反馈 - 为禁用状态的闹钟添加更明显的视觉区分
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 95a6d8137b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let lhsNext = store.nextTriggerDate(for: $0) | ||
| let rhsNext = store.nextTriggerDate(for: $1) |
There was a problem hiding this comment.
Stabilize sort comparisons with a single reference time
displayAlarms calls store.nextTriggerDate(for:) inside the sort predicate for both sides, and that helper uses Date() internally each time. Around trigger boundaries (for example, when the current minute rolls over during sorting), the same alarm can compare differently across predicate invocations, which violates sorted’s strict weak ordering requirement and can yield unstable ordering/flicker. Compute now once (or precompute each alarm’s next trigger once) before sorting to keep comparisons deterministic.
Useful? React with 👍 / 👎.
Summary
Testing