rzen/workouts
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Fix watch freeze on the progress flow; make Ready? always reachable

Browse Source 
Tapping an in-progress exercise on the watch froze the app in an infinite
SwiftUI re-render loop. WorkoutLogListView.body observed SwiftData two ways
the iPhone list deliberately avoids: a @Query-bound Split, and a traversal of
its `exercises` relationship during render (availableExercises). Reading an
observed model's relationship inside body keeps the view perpetually
subscribed and re-invalidating. Fix: fetch the split imperatively (not via
@Query), gate the Add-Exercise affordances on the value-type doc.splitID, and
evaluate availableExercises only from the picker sheet's closure. The list
body now depends solely on the value-type working doc.

Also remove the temporary on-screen diagnostics/PVDiag plumbing and restore
PhaseTimerLayout and the dot-row animation that were dropped while debugging.

Make the Ready? page always lead the exercise flow on both watch and iPhone
(previously only for not-started exercises), so a resumed run can swipe back
to it. A deliberate swipe back to Ready? resets the run; the transient paged
TabView snap-to-0 on open is guarded by a settle gate plus an adjacent-swipe
check, so an in-progress exercise lands on its set and is never reset on open.

Claude-Session: https://claude.ai/code/session_01SCv7zvGFcKy47KSTnTLxRe
This commit is contained in:
Rouslan Zenetl
2026-06-20 19:02:09 -04:00
parent 21ee05053e
commit 707d71eaf0
3 changed files with 91 additions and 90 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Workouts Watch App/Views/WorkoutLogListView.swift
+14 -13
View File
@@ -10,10 +10,7 @@ import SwiftData
struct WorkoutLogListView: View {
@Environment(WatchConnectivityBridge.self) private var bridge
/// The split this workout came from (read-only on the watch), used to offer
/// additional exercises that aren't logged yet.
@Query private var matchingSplits: [Split]
@Environment(\.modelContext) private var modelContext
/// Working copy of the workout. We drive the UI from this and mutate it on
/// every edit (then forward through the bridge) to avoid the read-after-write
@@ -25,15 +22,19 @@ struct WorkoutLogListView: View {
init(workout: Workout) {
_doc = State(initialValue: WorkoutDocument(from: workout))
if let splitID = workout.splitID {
_matchingSplits = Query(filter: #Predicate<Split> { $0.id == splitID })
} else {
// No source split: never match anything.
_matchingSplits = Query(filter: #Predicate<Split> { _ in false })
}
}
private var split: Split? { matchingSplits.first }
/// The split this workout came from (read-only on the watch), used to offer
/// additional exercises that aren't logged yet. Fetched imperatively — *not* via
/// `@Query` — so the list body never observes the live `Split` or traverses its
/// `exercises` relationship during a render. Doing so (a `@Query`-observed model
/// whose to-many relationship is read in `body`) drove a SwiftData re-render loop
/// that hung the watch. `availableExercises` is therefore only ever evaluated from
/// the picker sheet's closure, not from `body`.
private var split: Split? {
guard let splitID = doc.splitID else { return nil }
return CacheMapper.fetchSplit(id: splitID, in: modelContext)
}
private var sortedLogs: [WorkoutLogDocument] {
doc.logs.sorted { $0.order < $1.order }
@@ -58,7 +59,7 @@ struct WorkoutLogListView: View {
}
}
if !availableExercises.isEmpty {
if doc.splitID != nil {
Section {
Button {
showingExercisePicker = true
@@ -77,7 +78,7 @@ struct WorkoutLogListView: View {
ContentUnavailableView(
"No Exercises",
systemImage: "figure.strengthtraining.traditional",
description: Text(availableExercises.isEmpty
description: Text(doc.splitID == nil
? "No exercises in this workout."
: "Tap + to add exercises.")
)