From 91765d122d7528c354842172e92d252fd27723ad Mon Sep 17 00:00:00 2001 From: Shane Smiskol Date: Thu, 30 Apr 2026 05:31:38 -0700 Subject: [PATCH 1/2] fix: re-fetch route list after closing direct-link route view Visiting /dongleId/log_id directly takes a fast path that fetches just that one route via the segmentRange filter. The fetch then dispatched ACTION_ROUTES_METADATA with the full filter range as the covered range, so hasRoutesData reported true even though only one route had been loaded. Clicking X to close back to the dashboard left the user looking at a one-route list, since DriveList's checkRoutesData visibility hook saw cached metadata and didn't re-fetch. Mark the metadata range as null when the fetch was segment-scoped, so the next checkRoutesData (fired by DriveList becoming visible) fills in the full filter range. Co-Authored-By: Claude Opus 4.7 (1M context) --- src/actions/index.js | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/src/actions/index.js b/src/actions/index.js index c523161d..841c87eb 100644 --- a/src/actions/index.js +++ b/src/actions/index.js @@ -31,9 +31,13 @@ export function checkRoutesData() { console.debug('We need to update the segment metadata...'); const { dongleId } = state; const fetchRange = state.filter; + // Direct visits to /dongleId/log_id fetch only that one route for speed. + // Remember that so we don't claim to have covered the full filter range — + // otherwise hasRoutesData lies and the dashboard never re-fetches when the + // user clicks X to close the route view. + const isSegmentFetch = !!state.segmentRange; - // if requested segment range not in loaded routes, fetch it explicitly - if (state.segmentRange) { + if (isSegmentFetch) { routesRequest = { req: Drives.getRoutesSegments(dongleId, undefined, undefined, undefined, `${dongleId}|${state.segmentRange.log_id}`), dongleId, @@ -95,8 +99,11 @@ export function checkRoutesData() { dispatch({ type: Types.ACTION_ROUTES_METADATA, dongleId, - start: fetchRange.start, - end: fetchRange.end, + // null start/end means "we did not cover the full filter range" so the + // next checkRoutesData (e.g. when the user closes back to the dashboard) + // will refetch all routes for the active filter. + start: isSegmentFetch ? null : fetchRange.start, + end: isSegmentFetch ? null : fetchRange.end, routes, }); From baff7ee8ec4fec277b318463e7fd4384e4a54d1d Mon Sep 17 00:00:00 2001 From: Shane Smiskol Date: Thu, 30 Apr 2026 05:44:03 -0700 Subject: [PATCH 2/2] fire checkRoutesData on dashboard mount MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit VisibilityHandler in DriveList only triggers onVisible from visibilitychange/focus/blur events, not on mount. When the user clicks X to close a route view, the dashboard remounts but no fetch runs — the metadata fix from the previous commit is necessary but not sufficient on its own. Pass onInit so the handler fires once on mount; minInterval=60 still gates subsequent visibility events. checkRoutesData's own hasRoutesData check prevents redundant fetches when the cache is already valid. Co-Authored-By: Claude Opus 4.7 (1M context) --- src/components/Dashboard/DriveList.jsx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/components/Dashboard/DriveList.jsx b/src/components/Dashboard/DriveList.jsx index 355e13bc..198c5f1b 100644 --- a/src/components/Dashboard/DriveList.jsx +++ b/src/components/Dashboard/DriveList.jsx @@ -66,7 +66,7 @@ const DriveList = (props) => { return (
- dispatch(checkRoutesData())} minInterval={60} /> + dispatch(checkRoutesData())} minInterval={60} /> {content} {contentStatus}