Case study 09 / 17React Front-End
A unified alarm-acknowledgement workflow for control-room operators
One acknowledgement path for four entry points, with server-confirmed row states and one shared count: feedback in 74 ms, not up to 20 s.
Stack
- TypeScript
- React
- Next.js
- CSS animations
- CesiumJS
- postMessage
- MongoDB
01 · How it works
- TodaytoChanged in this work
- Data flow
What it does
Operators acknowledge alarms from an alarm table or from a beacon over the main 3D view; acknowledgement is how they record that an alarm has been seen, so the interface must never be ambiguous.
Read more
I rebuilt acknowledgement as one shared path for all four entry points and both system types. A click now confirms at once, every count agrees, and the beacon stays above the 3D map.
6 connections· select a part to trace it
- Operator to Shared acknowledge step: clicks acknowledge
- Shared acknowledge step to Alarm row: shows sending at oncechanged
- Shared acknowledge step to API: sends it, then 1 list reload
- API to Alarm store: saves ack, new timestamp
- API to Alarm row: list applied, no stamp check
- Shared acknowledge step to 3D map service: asks it to reload alarms
02Results
- R01Lower is better
Worst-case wait from click to row update
Before 20,000 ms, after 74 ms, 270× lower. Lower is better.BeforeAfter - R02Lower is better
Requests sent per acknowledgement
Before 8, after 1, 8× lower. Lower is better.BeforeAfter - R03Higher is better
Map checks with the beacon on top (of 8)
Before 0, after 8, from zero. Higher is better.BeforeAfter
What it achieved
- Feedback after a click: unchanged for up to 20 s → immediate, with sending, acknowledged and failed states
- Alarm counts: badge and list counted separately → one shared count, equal in 12 of 12 checks
Read more
- Beacon over the map with panels hidden: never on top → on top in 8 of 8 checks
- Failure handling: browser console only → a notice on the row if the alarm is still listed after 30 s
- Requests per acknowledgement: 8 → 1
The challenge
The server was never the bottleneck. It saved each acknowledgement and returned the updated list immediately, but the client discarded that response because its timestamp matched the previous one. The row stayed unchanged for up to 20 seconds and the button reset as if the action had failed.
Around that defect sat the structural problems: errors reached only the browser console, only one row could be in flight, and each acknowledgement refetched eight kinds of data.
Read more
Over the 3D map, the beacon disappeared when the side panels were hidden, and its badge and the alarm list kept separate counts. In an alarm workflow, each of these undermines operator trust.
What I learned
Before blaming the server, verify what the client does with a correct response. A timestamp guard discarded it; one reload that bypasses the guard, plus explicit per-row states, fixed it, and a row reads acknowledged only once the server confirms.
Read more
Layering defects rarely yield to a higher z-index: a backdrop filter trapped the beacon beneath the map, so it now renders through the map's own overlay layer. I also designed a calmer beacon; after review it was dropped, and I rebuilt the original on transform and opacity only.
Stack
- TypeScript
- React
- Next.js
- CSS animations
- CesiumJS
- postMessage
- MongoDB
Skills
- Interaction design
- State management
- Real-time UI
- Rendering performance
- Root-cause analysis
