fix UI-driven scanning/renaming

[stapelberg]

This feature is broken when running scan2drive on gokrazy, which is the only supported environment now.

[markdrayton]

Do you have any wider plans for the UI? I started chipping away at making the scan UI work again but got sidetracked with thoughts of what else might need doing.

In particular, the scan list is generated on the server side and doesn't update when a new scan is made. There's a comment somewhere about using web events to achieve this but another approach could be separating the UI into a REST API that the server exposes and a frontend that uses it. In this case it'd be much easier to trigger updates of the UI when a new scan is available (possibly using something like SWR or react query, though it's hard to be enthusiastic about dealing with Node/npm and that ball of magic).

I wanted to see if you had any thoughts on any of this before poking around. I see there's also a bit of overlap between thr httpingest API and what I suggested above.

[stapelberg]

In particular, the scan list is generated on the server side and doesn't update when a new scan is made.

Yeah, I typically only look at the web UI when troubleshooting something. Otherwise, I interact with my scan2drive instance via an M5Stack microcontroller running an M5ez based UI (https://github.com/M5ez/M5ez/issues/125), which in turn uses MQTT.

But, yes, if you’re scanning via the web UI, then it would indeed be nice if the list of scans was updated, at the very least when a new scan was triggered via the UI, but ideally whenever a new scan enters the system.

In this case it'd be much easier to trigger updates of the UI when a new scan is available (possibly using something like SWR or react query, though it's hard to be enthusiastic about dealing with Node/npm and that ball of magic).

Yeah, I understand the appeal of using some ready-made solution for keeping state updated.

scan2drive used to be on Polymer, but updating that turned out to be such a disproportionate amount of work that I switched to materialize in commit 8b1bcff230843bdb5856efd55865fd29dd6c3694, so I certainly share your distaste of npm and the fast-paced javascript ecosystem in general.

If we had to use a JavaScript framework, I would be more interested in Angular over React, purely based on it being the technology stack that’s more often used in my bubble. But ideally we didn’t need to resort to either.

I wonder if there is a solution that fits better into a minimalist Go project? In another projects, I ended up using the EventSource API (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events), which is actually not that much work if you only need it in one place, say, a scan list…

I hope that answers some of your questions, but feel free to ask follow-up questions if you have any :)

[markdrayton]

Hm, EventSource seems doable, and there's https://pkg.go.dev/github.com/donovanhide/eventsource for the server side. I'll do some when-I-find-time poking around with this.

[stapelberg]

EventSource is pretty easy to speak on the server side even without extra packages, BTW:

• w.Header().Set("Content-Type", "text/event-stream")
• wrap your JSON record in EventSource framing: rdr = bytes.NewReader(append(append([]byte("data: "), b...), []byte("\n\n")...))
• flush data to the client: if f, ok := w.(http.Flusher); ok { f.Flush() }

[markdrayton]

Yes, I saw that it looked straightforward and intended to see what else, if anything, a canned library offered (eg simplified error handing and so on).

The m5stack implementation sounds great and is very tempting, too..