feat: enhance charts and modals with dynamic handling and user feedback#165
Merged
Conversation
…n and tooltip support
…ut handling and calendar scroll range
…g and empty check
…rciseInfoScreen with dynamic chart data handling
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds chart-shaped exercise history and progression charts with metric toggles and pointer tooltips, refactors update-check errors to typed states with retry, changes global history queries to accept exerciseIds, memoises exercise IDs in workout views, and switches the Stats calendar to use allWorkouts with configurable past scroll range. ChangesUpdate Error Handling Refactor
Exercise Progression Chart with Metric Mode
Workout Screen Optimisations and Calendar Refinements
Sequence Diagram(s)sequenceDiagram
participant Screen as ExerciseInfoScreen
participant History as useExerciseHistoryQuery
participant ProgressChart as ExerciseProgressionChart
participant BodyChart as BodyMeasurementLineChart
Screen->>History: fetch history (sections + chartSets)
History-->>Screen: return sections + chartSets
Screen->>Screen: build chartExercise from chartSets
Screen->>ProgressChart: pass chartExercise + timeRange + units
ProgressChart->>ProgressChart: toggle metricMode (weight ↔ 1RM)
ProgressChart->>ProgressChart: compute chart points, y-axis, pointers
ProgressChart-->>Screen: render with metric toggle and tooltips
Screen->>BodyChart: pass body measurement data + timeRange
BodyChart->>BodyChart: compute yAxisOffset/yAxisMax and pointer labels
BodyChart-->>Screen: render with pointer tooltips
sequenceDiagram
participant Modal as UpdateModal
participant Hook as useAppUpdates
participant Expo as Updates
Hook->>Expo: checkForUpdateAsync()
alt update available
Expo-->>Hook: update available
Hook->>Expo: fetchUpdateAsync()
alt download succeeds
Expo-->>Hook: set isUpdateReady
else download fails
Hook->>Hook: set errorType = "download-failed"
Hook->>Modal: expose status + errorType
end
else check fails (first)
Hook->>Hook: retry after 5s (attempt(isRetry=true))
else check fails (second)
Hook->>Hook: set status = "no-update"
end
Hook-->>Modal: expose status + errorType
Modal->>Modal: switch on errorType to select UI and button action
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 4 issues, and left some high level feedback:
- Both
ExerciseProgressionChartandBodyMeasurementLineChartuseninsidepointerLabelComponent(idx === n - 1) butnis not defined in scope, which will throw at runtime; you likely wantconst n = chartData.lengthor equivalent in the closure. - In
UpdateModal,content.onPressis used unconditionally when rendering the button, butcontentcases withoutshowButtondon’t setonPress; tightening thecontenttype (e.g. a discriminated union keyed onshowButton) will prevent accidental missing handlers.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Both `ExerciseProgressionChart` and `BodyMeasurementLineChart` use `n` inside `pointerLabelComponent` (`idx === n - 1`) but `n` is not defined in scope, which will throw at runtime; you likely want `const n = chartData.length` or equivalent in the closure.
- In `UpdateModal`, `content.onPress` is used unconditionally when rendering the button, but `content` cases without `showButton` don’t set `onPress`; tightening the `content` type (e.g. a discriminated union keyed on `showButton`) will prevent accidental missing handlers.
## Individual Comments
### Comment 1
<location path="components/charts/ExerciseProgressionChart.tsx" line_range="505" />
<code_context>
+ const val = items[0]?.value;
+ if (val == null) return null;
+ const display = Number.isInteger(val) ? `${val}` : val.toFixed(1);
+ const isLast = idx === n - 1 && n > 1;
+ return (
+ <View style={[styles.tooltip, isLast && styles.tooltipLast]}>
</code_context>
<issue_to_address>
**issue (bug_risk):** The `n` variable used in `pointerLabelComponent` is undefined, which will throw at runtime.
In `pointerLabelComponent`, `const isLast = idx === n - 1 && n > 1;` uses `n`, which isn’t defined in this scope, so the tooltip will throw a ReferenceError on first render. If this is meant to be the total number of points, derive it once (e.g. `const n = chartData.length;` in the outer scope or inside the `useMemo` that builds `chartData`) and close over it here.
</issue_to_address>
### Comment 2
<location path="components/charts/BodyMeasurementLineChart.tsx" line_range="317" />
<code_context>
+ const val = items[0]?.value;
+ if (val == null) return null;
+ const display = Number.isInteger(val) ? `${val}` : val.toFixed(1);
+ const isLast = idx === n - 1 && n > 1;
+ return (
+ <View style={[styles.tooltip, isLast && styles.tooltipLast]}>
</code_context>
<issue_to_address>
**issue (bug_risk):** The `n` variable in the body measurement chart tooltip is also undefined and will crash when the tooltip renders.
Here `pointerLabelComponent` uses `n` without defining it, which will throw a ReferenceError when the tooltip renders. You likely want to compare `idx` with the last index of `chartData`/`dataPoints`, e.g. compute `const n = chartData.length;` in the component body and close over it in the callback.
</issue_to_address>
### Comment 3
<location path="components/charts/ExerciseProgressionChart.tsx" line_range="246" />
<code_context>
const { width: screenWidth } = useWindowDimensions();
- const chartData = useMemo(() => {
+ const { chartData, yAxisOffset, yAxisMax } = useMemo(() => {
const buckets = groupMeasurementsByTime(data, timeRange);
// Only include buckets with actual data — measurements are point-in-time
</code_context>
<issue_to_address>
**issue (complexity):** Consider extracting the chart calculation, pointer configuration, and metric toggle logic into small helper functions/components so `ExerciseProgressionChart` remains a thin orchestrator instead of holding all cross-cutting behavior inline.
The new features are good, but they’ve made `ExerciseProgressionChart` carry a lot of cross‑cutting logic. You can keep all behavior and reduce complexity by extracting a few focused helpers.
### 1. Break up the `useMemo` closure
The current `useMemo` handles:
- metric mode → sets remapping
- bucketing + forward fill
- baseline application
- y‑axis range calculation
- dataPoint shaping + tooltip support (`hasData`)
You can preserve behavior by pulling this into small pure helpers and keeping `useMemo` as orchestration. For example:
```ts
type MetricMode = "1rm" | "weight";
type ChartPoint = {
value: number;
label: string | undefined;
labelComponent: (() => React.JSX.Element) | undefined;
dataPointColor: string;
dataPointRadius: number;
hasData: boolean;
};
type ChartCalcResult = {
chartData: ChartPoint[];
yAxisOffset: number;
yAxisMax: number | undefined;
};
const EMPTY_CHART_RESULT: ChartCalcResult = {
chartData: [],
yAxisOffset: 0,
yAxisMax: undefined,
};
function buildSetsForChart(
sets: CompletedSet[],
metricMode: MetricMode,
showMetricToggle: boolean,
): CompletedSet[] {
if (metricMode !== "weight" || !showMetricToggle) return sets;
return sets.map((s) => ({
...s,
progressionMetric: s.weight,
}));
}
function applyForwardFill(buckets: ReturnType<typeof groupSetsByTime>) {
let lastValue: number | null = null;
for (let i = 0; i < buckets.length; i++) {
if (buckets[i].hasData) {
lastValue = buckets[i].value;
} else if (lastValue !== null) {
buckets[i] = { ...buckets[i], value: lastValue };
}
}
}
function applyBaseline({
buckets,
metricMode,
preRangeBaseline,
isWeightTypePre,
conversionFactor,
}: {
buckets: ReturnType<typeof groupSetsByTime>;
metricMode: MetricMode;
preRangeBaseline: number | null | undefined;
isWeightTypePre: boolean;
conversionFactor: number;
}) {
const rawBaseline =
metricMode === "1rm" && preRangeBaseline != null
? isWeightTypePre
? preRangeBaseline * conversionFactor
: preRangeBaseline
: undefined;
const baselineValue =
rawBaseline != null && rawBaseline > 0 ? rawBaseline : undefined;
if (baselineValue == null) return;
for (let i = 0; i < buckets.length; i++) {
if (buckets[i].value === null) {
buckets[i] = { ...buckets[i], value: baselineValue };
}
}
}
function bucketsToChartData(
buckets: ReturnType<typeof groupSetsByTime>,
): ChartPoint[] {
return buckets.map((bucket) => {
const metric = bucket.value ?? 0;
const labelComponent = bucket.labelLine2
? () => (
<View style={styles.twoLineLabel}>
<Text style={styles.twoLineLabelText}>{bucket.label}</Text>
<Text style={styles.twoLineLabelText}>{bucket.labelLine2}</Text>
</View>
)
: undefined;
return {
value: metric,
label: labelComponent ? undefined : bucket.label,
labelComponent,
dataPointColor: bucket.hasData ? Colors.dark.tint : "transparent",
dataPointRadius: 4,
hasData: bucket.hasData,
};
});
}
function computeYAxisRange(values: number[]): {
offset: number;
max: number;
} {
const minVal = Math.min(...values);
const maxVal = Math.max(...values);
if (minVal > 0) {
const range = maxVal - minVal;
const padding = Math.max(range * 0.15, 0.5);
const offset = minVal - padding;
const max = maxVal + padding - offset;
return { offset, max };
}
const padding = Math.max(maxVal * 0.15, 0.5);
return { offset: 0, max: maxVal + padding };
}
```
Then `useMemo` becomes mostly wiring, which is much easier to mentally follow and unit‑test:
```ts
const { chartData, yAxisOffset, yAxisMax } = useMemo<ChartCalcResult>(() => {
const setsForChart = buildSetsForChart(
exercise.completed_sets,
metricMode,
showMetricToggle,
);
const buckets = groupSetsByTime(
setsForChart,
timeRange,
exercise.tracking_type,
conversionFactor,
);
if (buckets.length === 0) return EMPTY_CHART_RESULT;
applyForwardFill(buckets);
const isWeightTypePre =
exercise.tracking_type === null ||
exercise.tracking_type === "weight" ||
exercise.tracking_type === "assisted";
applyBaseline({
buckets,
metricMode,
preRangeBaseline,
isWeightTypePre,
conversionFactor,
});
if (!buckets.some((b) => b.value !== null)) return EMPTY_CHART_RESULT;
const chartData = bucketsToChartData(buckets);
const vals = chartData.map((p) => p.value);
const { offset, max } = computeYAxisRange(vals);
return { chartData, yAxisOffset: offset, yAxisMax: max };
}, [
exercise.completed_sets,
exercise.tracking_type,
timeRange,
conversionFactor,
preRangeBaseline,
metricMode,
showMetricToggle,
]);
```
This keeps behavior identical but isolates baseline/forward‑fill/range logic into small helpers and makes the `EMPTY_CHART_RESULT` type explicit.
### 2. Extract pointer / tooltip configuration
The inline `pointerConfig` closure is quite dense and closes over `chartData`, `n`, and `tooltipUnit`. Extracting it into a helper keeps the JSX readable:
```ts
type PointerConfigProps = {
chartData: ChartPoint[];
pointCount: number;
tooltipUnit: string;
};
function buildExercisePointerConfig({
chartData,
pointCount,
tooltipUnit,
}: PointerConfigProps) {
return {
activatePointersInstantlyOnTouch: true,
persistPointer: true,
showPointerStrip: true,
pointerStripColor: "rgba(255,255,255,0.15)",
pointerStripWidth: 1,
pointerColor: Colors.dark.highlight,
radius: 5,
pointerLabelWidth: POINTER_LABEL_WIDTH,
pointerLabelHeight: 34,
autoAdjustPointerLabelPosition: true,
shiftPointerLabelY: -44,
pointerLabelComponent: (
items: { value: number }[],
_secondary: unknown,
idx: number,
) => {
if (!chartData[idx]?.hasData) return null;
const val = items[0]?.value;
if (val == null) return null;
const display = Number.isInteger(val) ? `${val}` : val.toFixed(1);
const isLast = idx === pointCount - 1 && pointCount > 1;
return (
<View style={[styles.tooltip, isLast && styles.tooltipLast]}>
<Text style={styles.tooltipText}>
{tooltipUnit ? `${display} ${tooltipUnit}` : display}
</Text>
</View>
);
},
} as const;
}
```
Usage becomes much cleaner:
```tsx
const n = chartData.length;
<LineChart
// ...
yAxisOffset={yAxisOffset}
maxValue={yAxisMax}
pointerConfig={buildExercisePointerConfig({
chartData,
pointCount: n,
tooltipUnit,
})}
/>
```
You keep all tooltip behavior but remove a large nested object from the JSX.
### 3. Move the metric toggle into a tiny component
The toggle’s layout/styling is mixed into the main component. Extracting it into a dumb presentational component leaves `ExerciseProgressionChart` concerned only with the selected mode:
```ts
type MetricModeToggleProps = {
mode: MetricMode;
onChange: (mode: MetricMode) => void;
};
const MetricModeToggle: React.FC<MetricModeToggleProps> = ({ mode, onChange }) => (
<View style={styles.metricToggleRow}>
{(["1rm", "weight"] as const).map((m) => {
const active = mode === m;
const label = m === "1rm" ? "1RM" : t`Weight`;
return (
<TouchableOpacity
key={m}
onPress={() => onChange(m)}
style={[styles.metricPill, active && styles.metricPillActive]}
activeOpacity={0.7}
>
<Text
style={[
styles.metricPillLabel,
active && styles.metricPillLabelActive,
]}
>
{label}
</Text>
</TouchableOpacity>
);
})}
</View>
);
```
Then in the main component:
```tsx
{showMetricToggle && (
<MetricModeToggle mode={metricMode} onChange={setMetricMode} />
)}
```
This keeps all current functionality but prevents `ExerciseProgressionChart` from becoming a “god” component and makes each concern (data shaping, y‑axis range, tooltip behavior, UI toggle) testable and easier to reason about.
</issue_to_address>
### Comment 4
<location path="components/charts/BodyMeasurementLineChart.tsx" line_range="214" />
<code_context>
const { width: screenWidth } = useWindowDimensions();
- const chartData = useMemo(() => {
+ const { chartData, yAxisOffset, yAxisMax } = useMemo(() => {
const buckets = groupMeasurementsByTime(data, timeRange);
// Only include buckets with actual data — measurements are point-in-time
</code_context>
<issue_to_address>
**issue (complexity):** Consider extracting the Y-axis range math and tooltip renderer into small helpers and passing `n` explicitly to simplify the chart component and make the logic reusable.
You can reduce the added complexity without changing behavior by extracting two small helpers and making the `n` dependency explicit.
### 1. Extract Y‑axis range computation
Right now the main `useMemo` computes both the data points and the y‑axis range. You can keep functionality identical while separating concerns slightly:
```ts
const computeYAxisRange = (values: number[]) => {
const minVal = Math.min(...values);
const maxVal = Math.max(...values);
const range = maxVal - minVal;
const padding = Math.max(range * 0.15, 0.5);
const yMin = minVal - padding;
const yMax = maxVal + padding;
return { yAxisOffset: yMin, yAxisMax: yMax - yMin };
};
```
Then reuse it inside the memo:
```ts
const { chartData, yAxisOffset, yAxisMax } = useMemo(() => {
const buckets = groupMeasurementsByTime(data, timeRange);
const dataPoints = buckets.filter((b) => b.hasData);
if (dataPoints.length === 0) {
return { chartData: [], yAxisOffset: 0, yAxisMax: 100 };
}
const values = dataPoints.map((b) => b.value ?? 0);
const { yAxisOffset, yAxisMax } = computeYAxisRange(values);
const chartData = dataPoints.map((bucket) => {
const labelComponent = bucket.labelLine2
? () => (
<View style={styles.twoLineLabel}>
<Text style={styles.twoLineLabelText}>{bucket.label}</Text>
<Text style={styles.twoLineLabelText}>{bucket.labelLine2}</Text>
</View>
)
: undefined;
return {
value: bucket.value ?? 0,
label: labelComponent ? undefined : bucket.label,
labelComponent,
dataPointColor: Colors.dark.tint,
dataPointRadius: 4,
};
});
return { chartData, yAxisOffset, yAxisMax };
}, [data, timeRange]);
```
This keeps the logic the same but makes the Y‑axis math easier to reuse (e.g., in `ExerciseProgressionChart`).
### 2. Extract tooltip renderer and make `n` explicit
The tooltip logic is long and closes over `n`. You can both shorten the JSX and make the dependency explicit by extracting a small renderer:
```ts
const renderMeasurementTooltip = (
unit: string,
n: number,
): ((items: { value: number }[], _secondary: unknown, idx: number) => JSX.Element | null) =>
(items, _secondary, idx) => {
const val = items[0]?.value;
if (val == null) return null;
const display = Number.isInteger(val) ? `${val}` : val.toFixed(1);
const isLast = idx === n - 1 && n > 1;
return (
<View style={[styles.tooltip, isLast && styles.tooltipLast]}>
<Text style={styles.tooltipText}>
{display} {unit}
</Text>
</View>
);
};
```
Then use it in the chart, passing `n` explicitly:
```tsx
const n = chartData.length;
<LineChart
key={timeRange}
data={chartData}
width={chartWidth}
spacing={spacing}
initialSpacing={initialSpacing}
endSpacing={initialSpacing}
// ...
yAxisOffset={yAxisOffset}
maxValue={yAxisMax}
pointerConfig={{
activatePointersInstantlyOnTouch: true,
persistPointer: true,
showPointerStrip: true,
pointerStripColor: "rgba(255,255,255,0.15)",
pointerStripWidth: 1,
pointerColor: Colors.dark.highlight,
radius: 5,
pointerLabelWidth: POINTER_LABEL_WIDTH,
pointerLabelHeight: 34,
autoAdjustPointerLabelPosition: true,
shiftPointerLabelY: -44,
pointerLabelComponent: renderMeasurementTooltip(unit, n),
}}
/>
```
If `ExerciseProgressionChart` uses the same pointer behavior, you can move `renderMeasurementTooltip` (and/or a `buildPointerConfig`) into a shared module and parametrize `unit` / formatting, which will reduce duplication across both charts while keeping all behavior unchanged.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@hooks/useExerciseDetailQuery.ts`:
- Line 156: The code is incorrectly forcing a nullable trackingType to string
(tracking_type: trackingType as string) which contradicts the downstream
handling and the actual nullable semantics; update useExerciseDetailQuery (and
the historyData.trackingType usage in app/(app)/exercise-info.tsx) to preserve
the nullable type (pass tracking_type: trackingType or explicitly typed as
string | null) and update the shared type TrackedExerciseWithSets or its
consumers so tracking_type is consistently string | null across the codebase,
ensuring all callers (e.g., hooks/useTrackedExercisesQuery.ts and
components/charts/ExerciseProgressionChart.tsx) accept the nullable value rather
than casting away nullability.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 81b911cb-33ee-4143-8992-bdb56e351a0d
📒 Files selected for processing (11)
app/(app)/(tabs)/(stats)/index.tsxapp/(app)/(workout)/index.tsxapp/(app)/exercise-info.tsxcomponents/UpdateModal.tsxcomponents/charts/BodyMeasurementLineChart.tsxcomponents/charts/ExerciseProgressionChart.tsxcomponents/stats/WorkoutCalendarModal.tsxhooks/useAppUpdates.tshooks/useCompletedWorkoutsQuery.tshooks/useExerciseDetailQuery.tshooks/useExerciseHistoryQuery.ts
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/(app)/(tabs)/(stats)/history-details.tsx (1)
288-292:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winInconsistent null handling for
set.reps.On line 278,
set.reps ?? 0guards against null values when displaying reps for the "reps" tracking type. However, lines 290 and 298 display{set.reps}directly without null coalescing for "weight" and "assisted" tracking types. Ifset.repsis null (as confirmed by the upstream contract inindex.tsx), these lines would render "null Reps" or display unexpectedly. Apply consistent null handling across all tracking types.🛡️ Proposed fix for consistent null handling
<ThemedText style={styles.setText}> <Trans> - {set.weight} {settings?.weightUnit} | {set.reps} Reps + {set.weight} {settings?.weightUnit} | {set.reps ?? 0} Reps </Trans> </ThemedText><ThemedText style={styles.setText}> <Trans> Assist {set.weight} {settings?.weightUnit} | Resist{" "} {bodyWeight - (set.weight || 0)}{" "} - {settings?.weightUnit} | {set.reps} Reps + {settings?.weightUnit} | {set.reps ?? 0} Reps </Trans> </ThemedText>Also applies to: 294-300
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/`(app)/(tabs)/(stats)/history-details.tsx around lines 288 - 292, Several JSX renderings in history-details.tsx use {set.reps} directly for the "weight" and "assisted" tracking types (inside ThemedText elements that also show settings?.weightUnit), which can render "null Reps"; update those occurrences to use null-coalescing (set.reps ?? 0) like the "reps" case. Locate the ThemedText nodes that show "{set.weight} {settings?.weightUnit} | {set.reps} Reps" and the similar assisted/tracking-type blocks and replace {set.reps} with {set.reps ?? 0}; also scan the component for any other direct uses of set.reps and apply the same fix.
🧹 Nitpick comments (1)
app/(app)/(tabs)/(stats)/history-details.tsx (1)
277-281: 💤 Low valueConsider alternative display for null reps.
Whilst
set.reps ?? 0correctly ensures the<Plural>component receives a numeric value, displaying "0 Reps" when reps is null may not convey the intended meaning. Consider whether rendering "—" or conditionally omitting the display whenset.repsis null would provide clearer feedback to users.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/`(app)/(tabs)/(stats)/history-details.tsx around lines 277 - 281, The current render uses <Plural value={set.reps ?? 0} ... /> which forces a "0 Reps" display when set.reps is null; change the rendering logic in history-details.tsx to treat null/undefined differently by conditionally rendering the <Plural> component only when set.reps is a number (e.g., check Number.isFinite(set.reps) or set.reps != null) and otherwise render a placeholder like "—" or omit the element entirely; update the JSX around the <Plural> usage so the UI shows the placeholder/hidden state for null reps instead of "0 Reps".
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@app/`(app)/(tabs)/(stats)/history-details.tsx:
- Around line 288-292: Several JSX renderings in history-details.tsx use
{set.reps} directly for the "weight" and "assisted" tracking types (inside
ThemedText elements that also show settings?.weightUnit), which can render "null
Reps"; update those occurrences to use null-coalescing (set.reps ?? 0) like the
"reps" case. Locate the ThemedText nodes that show "{set.weight}
{settings?.weightUnit} | {set.reps} Reps" and the similar assisted/tracking-type
blocks and replace {set.reps} with {set.reps ?? 0}; also scan the component for
any other direct uses of set.reps and apply the same fix.
---
Nitpick comments:
In `@app/`(app)/(tabs)/(stats)/history-details.tsx:
- Around line 277-281: The current render uses <Plural value={set.reps ?? 0} ...
/> which forces a "0 Reps" display when set.reps is null; change the rendering
logic in history-details.tsx to treat null/undefined differently by
conditionally rendering the <Plural> component only when set.reps is a number
(e.g., check Number.isFinite(set.reps) or set.reps != null) and otherwise render
a placeholder like "—" or omit the element entirely; update the JSX around the
<Plural> usage so the UI shows the placeholder/hidden state for null reps
instead of "0 Reps".
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5c1c948f-5614-418a-a827-ffa09430e9a0
📒 Files selected for processing (4)
app/(app)/(tabs)/(stats)/history-details.tsxapp/(app)/exercise-info.tsxhooks/useExerciseDetailQuery.tshooks/useTrackedExercisesQuery.ts
✅ Files skipped from review due to trivial changes (1)
- hooks/useTrackedExercisesQuery.ts
This was referenced May 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
Enhance chart interactions, app update handling, and workout history navigation for a smoother and more informative user experience.
New Features:
Bug Fixes:
Enhancements:
Summary by CodeRabbit
New Features
Improvements