2.6 KiB
TASK-QUALITY-04 — pendingSaveRef as boolean Redundant Cast in useAutoSave
Where found
frontend/src/hooks/useAutoSave.ts. The code contains if (pendingSaveRef.current as boolean) where pendingSaveRef is already typed as React.MutableRefObject<boolean>. The as boolean cast is redundant and suggests the author was uncertain about the type.
Goal
Remove the cast: if (pendingSaveRef.current). Run TypeScript type-check to confirm no error is introduced.
Possible traps and issues
- None. This is a one-line cleanup.
Docs changes needed None required.
Why this is needed Redundant type assertions are noise that makes reviewers second-guess the type system. They also suppress TypeScript errors in cases where the cast is actually incorrect.
TASK-QUALITY-05 — console.warn in MapPage Provides No User Feedback for Threshold Errors
Where found
frontend/src/pages/MapPage.tsx lines ~148–151:
useEffect(() => {
if (mapThresholdError) {
console.warn("Failed to load map color thresholds:", mapThresholdError);
}
}, [mapThresholdError]);
When the threshold fetch fails the map silently falls back to hardcoded defaults. The user has no indication that their custom thresholds are not being applied.
Goal
Replace the console.warn with a small inline MessageBar or tooltip near the map legend that indicates thresholds could not be loaded and defaults are in use. The console.warn should be removed from production-facing code.
Possible traps and issues
- The fallback behaviour (using hardcoded defaults) is correct and the map should still render. The notification should be non-blocking (not a modal or full-page error).
- If the threshold fetch failing is expected in certain deployment configurations (e.g. feature not configured), an info-level message rather than a warning may be more appropriate.
Docs changes needed None required.
Why this is needed
console.warn is invisible to end users. If a custom threshold configuration is silently not applied, the map colour coding may be misleading with no indication of why.
TASK-QUALITY-06 — console.log Leaked in HistoryPage.test.tsx
Where found
frontend/src/pages/__tests__/HistoryPage.test.tsx line 8. A console.log statement was left in the test file, likely from a debugging session.
Goal
Remove the console.log call.
Possible traps and issues
- None.
Docs changes needed None required.
Why this is needed Debug logs in test files pollute the test runner output and make it harder to spot real failures or warnings.