mirror of
https://github.com/MarekWo/mc-webui.git
synced 2026-10-31 08:01:57 +01:00
MarekWoandClaude Opus 5
67b5e02d96
Expanding a Settings section fired one `get` per field, each a full mesh round-trip. Seven questions to a repeater four hops away, answered one at a time, to change the one field you came for -- and often a batch that timed out halfway and left the section blank. Nothing is read until asked for now: - every field has its own read button beside the control (same row, so no extra line per field), and `Read all fields` at the top of the section still does the whole batch - GET /settings takes an optional `fields=` subset so a single field is a single round-trip; the section still defines the order - reads are queued client-side. The device already serializes CLI traffic behind one lock, so parallel requests would only tie up server threads waiting for it - values are remembered per repeater in localStorage, so a section opens with the last readings instead of empty boxes. A remembered value is a usable baseline -- Apply writes an absolute value, so editing from a stale reading still sets what was typed -- and is marked with a clock per field plus a note at the foot of the section saying when it was read. Apply and unsupported replies update the cache too - a failed read no longer wipes what is on screen: the remembered value stays, still editable, still marked - field hints moved from a text block under the control into an info icon by the field name (the pattern the app's own Settings modal uses), and every field has one now instead of the 9 that did Verified against a live repeater from the local container: expanding all 8 sections makes 0 requests, a single-field read sends exactly `?section=advanced&fields=rxdelay`, the value survives a reload from cache with the stale note, and Apply still round-trips (dutycycle rewritten to its own value). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>