Skip to content

Frontend (on-device web UI)

Frontend source code lives in frontend/.

It is a Single Page App that is built into the firmware image:

  • Build output goes to main/frontend/
  • Firmware serves it under /
  • The UI calls the REST API under /api/* (same origin on-device)

Start here

Important constraints

  • Output is tuned for SPIFFS: stable filenames and gzip-only assets (see frontend_readme.md).
  • UI should tolerate mode differences (aircraft vs winch) and endpoints that are not registered / return 404 depending on firmware build flags and device mode.

Aircraft live IAS page

  • Route: /aircraft/live (AircraftLive.tsx)
  • Stream: useAircraftMonitor opens wss://…/api/live only while the page is mounted and the browser tab is visible (a hidden tab releases the TLS session)
  • The server pushes a snapshot when IAS or flight phase changes (at most every 200 ms). The page sends a text ping every 5 s.
  • Graph samples: recorded only in airborne and landing_hold; cleared on landed and on manual reset

Winch mode opens the same socket only on / (WinchMonitorProvider), and only while that tab is visible. History and settings do not hold it.

Hardware error banner

AppFrame polls GET /api/hw/errors once every 30 seconds, and skips the tick while the browser tab is hidden. Each latched code is a persistent alert above the page, not a toast. Dismissing one calls DELETE /api/hw/errors?code=… for that code only.

Develop against a real device via proxy

Use the Vite proxy workflow in frontend_readme.md so the UI talks to a device under /api/* while you iterate locally.