05543529e4
Nine task files matching Phase 1's shape (Goal / Deliverables / Spec / Acceptance / Risks / Done). README updated with full sequencing diagram, files-modified outline, tech stack additions, design rules, and phase acceptance. | # | Task | | --- | --------------------------------------------------------------------- | | 2.1 | MapView singleton + mapReady gate | | 2.2 | Tile-source switcher (Esri / OpenTopoMap / OSM / optional Google) | | 2.3 | Sprite preload — 7 racing categories x 4 colour variants | | 2.4 | WS client + rAF coalescer + Zustand position store + connection store | | 2.5 | MapPositions — clustered + selected sources | | 2.6 | MapTrails — bounded ring buffer, polyline rendering | | 2.7 | Event picker — TanStack Query + WS subscription orchestration | | 2.8 | Camera control trio — default-fit / selected-follow / one-shot | | 2.9 | Connection status + per-device last-seen indicators | Sequencing: 2.1 and 2.4 are parallel foundations (singleton vs data pipeline). Once both land, 2.5 / 2.6 / 2.7 / 2.9 fan out independently. 2.2 / 2.3 only need 2.1. 2.8 sits at the end on top of 2.1 + 2.5. Each task documents its deliverables down to file paths + interface shapes, includes concrete code sketches in the Specification, lists explicit out-of-scope items, and surfaces risks for the implementer to think about. An agent (or future me) can pick up any single task and ship it without re-deriving the design from the wiki. Resolved Phase 2 design decisions baked into the task files: - Trails: flat-colour-per-device for v1, defer speed-coloured segments to a Phase 3 polish task. - Cluster params: 14/50 (traccar default); tune after seeing real data. - Event picker placement: top-left dropdown. - Multi-event: out — single-select, one event at a time. - Stale-position visual: fade icon opacity; defer warning badges.
151 lines
7.7 KiB
Markdown
151 lines
7.7 KiB
Markdown
# Task 2.9 — Connection status + per-device last-seen indicators
|
|
|
|
**Phase:** 2 — Live monitoring map
|
|
**Status:** ⬜ Not started
|
|
**Depends on:** 2.4.
|
|
**Wiki refs:** `docs/wiki/concepts/maps-architecture.md` §"Visible system state".
|
|
|
|
## Goal
|
|
|
|
Show operators *just enough* about system state so they can answer two questions at a glance:
|
|
|
|
1. "Is the SPA still connected to live data?" — global WS status.
|
|
2. "Is this specific device still reporting?" — per-device last-seen age.
|
|
|
|
Not noisy. Subtle UI; not banners and modal warnings. The design ethos: operators trust the map until something goes wrong, at which point they need a quick read of *what* went wrong without a wall of red.
|
|
|
|
## Deliverables
|
|
|
|
- **`src/ui/components/connection-chip.tsx`** — `<ConnectionChip />` rendered in the monitor route's chrome (top-right corner of the map UI, near the basemap switcher). Reads `useConnectionStore`. Three visible states:
|
|
- **Connected** — small green dot, hidden text (or "Live" only on hover/expand). Subtle.
|
|
- **Reconnecting** — amber dot pulsing, text "Reconnecting…" with attempt count if useful.
|
|
- **Disconnected / offline** — red dot, text "Offline — last live: 14:02:11" showing the last successful contact time.
|
|
- **`src/ui/components/device-last-seen.tsx`** — `<DeviceLastSeen deviceId>` component. Renders nothing in normal state; renders a small subscript / icon when the device's last position is older than threshold (default: 60s).
|
|
- Used inside `<MapPositions>`'s feature properties (or as a separate symbol layer keyed off the `lastSeenAge` derived field), and in any future per-device sidebar.
|
|
- **`src/live/connection-store.ts`** updated — adds `lastConnectedAt: number | null` (already in 2.4's spec) and `lastDisconnectedAt: number | null`. Toast / chip use these for "last live: N min ago" formatting.
|
|
- **`src/live/last-seen.ts`** — utility: `formatLastSeen(ts: number, now = Date.now()): string` returns `"now"` / `"5s ago"` / `"2m ago"` / `"14:02"` based on age. Used by both the chip and the per-device indicator.
|
|
- **A "stale-position" derived signal** — at coalescer flush time, the position store can compute `staleByDevice: Set<string>` for devices whose last update is older than `STALE_THRESHOLD_MS` (default 60s). Map layers reading this Set apply a faded-icon variant. Or: a separate symbol layer renders a "warning" badge over stale devices' markers.
|
|
|
|
## Specification
|
|
|
|
### `<ConnectionChip />`
|
|
|
|
```tsx
|
|
export function ConnectionChip() {
|
|
const status = useConnectionStore((s) => s.status);
|
|
const lastConnectedAt = useConnectionStore((s) => s.lastConnectedAt);
|
|
|
|
if (status === 'connected') {
|
|
return (
|
|
<div className="flex items-center gap-1.5 text-xs">
|
|
<span className="w-2 h-2 rounded-full bg-green-500" aria-hidden />
|
|
<span className="text-muted-foreground">Live</span>
|
|
</div>
|
|
);
|
|
}
|
|
|
|
if (status === 'connecting' || status === 'reconnecting') {
|
|
return (
|
|
<div className="flex items-center gap-1.5 text-xs">
|
|
<span className="w-2 h-2 rounded-full bg-amber-500 animate-pulse" aria-hidden />
|
|
<span className="text-muted-foreground">
|
|
{status === 'connecting' ? 'Connecting…' : 'Reconnecting…'}
|
|
</span>
|
|
</div>
|
|
);
|
|
}
|
|
|
|
return (
|
|
<div className="flex items-center gap-1.5 text-xs">
|
|
<span className="w-2 h-2 rounded-full bg-destructive" aria-hidden />
|
|
<span className="text-destructive">
|
|
Offline {lastConnectedAt ? `· last live ${formatLastSeen(lastConnectedAt)}` : ''}
|
|
</span>
|
|
</div>
|
|
);
|
|
}
|
|
```
|
|
|
|
Position: top-right of the monitor route, in a small horizontal bar with the basemap switcher and other controls. Inline-flex.
|
|
|
|
### Per-device last-seen — two strategies
|
|
|
|
**Strategy A: Faded marker.** A separate symbol layer with a `'icon-opacity'` expression based on a `staleSec` property on each feature:
|
|
|
|
```ts
|
|
'icon-opacity': [
|
|
'interpolate', ['linear'], ['get', 'staleSec'],
|
|
0, 1.0, // fresh
|
|
60, 1.0, // 60s — full opacity
|
|
300, 0.4, // 5min — faded
|
|
1800, 0.2, // 30min — very faded
|
|
],
|
|
```
|
|
|
|
The position store includes `staleSec` in each feature's properties at coalescer-flush time.
|
|
|
|
**Strategy B: Badge / overlay.** A second symbol layer drawing a small "no-signal" icon over stale markers, filtered to `['>=', ['get', 'staleSec'], 60]`.
|
|
|
|
**Pick A for v1.** Simpler, fewer layers, cleaner visually. B can layer on top later if A isn't legible enough.
|
|
|
|
### Updating `staleSec`
|
|
|
|
Recomputed every second by a setInterval inside the position store (not on every position update — that would invalidate `latestByDevice` constantly):
|
|
|
|
```ts
|
|
// In src/live/position-store.ts
|
|
let staleTickerId: ReturnType<typeof setInterval> | null = null;
|
|
|
|
function startStaleTicker() {
|
|
if (staleTickerId) return;
|
|
staleTickerId = setInterval(() => {
|
|
const now = Date.now();
|
|
set((state) => {
|
|
// Only bump versionTick if any device's stale-bucket changed.
|
|
// ... or just trigger subscribers wholesale every second.
|
|
return { stalenessTick: now };
|
|
});
|
|
}, 1000);
|
|
}
|
|
```
|
|
|
|
Map layers re-derive `staleSec` from `latestByDevice` + `stalenessTick` on every flush. The store doesn't mutate position data; it just bumps a version tick that triggers selectors that compute `staleSec` themselves.
|
|
|
|
### Logout / unmount cleanup
|
|
|
|
The stale ticker runs as long as the SPA is mounted. Stop on logout (status flips to anonymous) or when navigating away from `/monitor`. Use a `useEffect` in `<MonitorPage>`:
|
|
|
|
```tsx
|
|
useEffect(() => {
|
|
startStaleTicker();
|
|
return () => stopStaleTicker();
|
|
}, []);
|
|
```
|
|
|
|
### What this task does NOT include
|
|
|
|
- **Loud "device offline!" notifications.** No toast, no modal. The faded icon is the signal. If operators need louder, Phase 3.4's per-device detail panel can add an alert badge.
|
|
- **Per-event "X devices offline" summary.** Phase 3 polish.
|
|
- **Auto-recovery testing for the WS reconnect.** That's covered by 2.4's acceptance.
|
|
- **Notification API integration.** Browser push on disconnect — Phase 4.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] `pnpm typecheck`, `pnpm lint`, `pnpm format:check`, `pnpm build` clean.
|
|
- [ ] On `/monitor`, the connection chip top-right shows "Live" with a green dot during normal operation.
|
|
- [ ] Disconnecting the network: the chip flips to "Reconnecting…" within a few seconds; on reconnect, back to "Live"; on permanent disconnect (close + no reconnect for 30s+), shows "Offline · last live HH:MM:SS".
|
|
- [ ] A device that hasn't reported in 5+ minutes appears noticeably faded on the map (not invisible — operators still see *where it was last seen*).
|
|
- [ ] On a fresh page load with no positions yet, the chip says "Connecting…" briefly, then "Live" once the snapshot arrives.
|
|
- [ ] No banner / toast spam during normal operation.
|
|
|
|
## Risks / open questions
|
|
|
|
- **Threshold tuning.** 60s = "fresh", 5min = "fading", 30min = "stale". For Teltonika devices reporting at 1Hz this is generous; for 0.2Hz devices the 60s window catches a device that just paused at a checkpoint. Watch dogfood data and adjust.
|
|
- **Setinterval ticker accuracy.** `setInterval(1000ms)` is approximate; on a slow tab it can drift. The visual effect doesn't need wall-clock precision — "this marker is faded because it's been a while" is still correct even if the timer drifted by a few seconds.
|
|
- **Race with reconnect on offline.** If the SPA is offline and reconnects, the snapshot replays; some markers' last-seen will jump from "stale" to "fresh" in one frame. Verify the visual transition is clean (no flicker).
|
|
- **Connection chip during boot.** Right after login, the WS hasn't connected yet — chip says "Connecting…". Should this be its own state, or just folded into "reconnecting"? Spec above keeps `connecting` distinct for clarity; either is defensible.
|
|
|
|
## Done
|
|
|
|
(Filled in when the task lands.)
|