Add QR scanner data collection

[jkleiber]

Summary
A normal QR scanner will just copypasta information into a text file. We should handle that in the batch uploader introduced in #78 by adding a "text" mode for the data input type (vs. the implicitly expected JSON mode).

The idea here is to create a JSON array of scanned data (JSON objects) and then process the data in CSV or upload mode as normal

Work Required

• Add a mode switch for text vs. json input
• Create JSON array from text data
• Pipe each input mode into the output modes

[godmar]

I talked with @aidnem and @j0shuaS yesterday a bit about the scouting app.

Is improving offline support a priority and if so, is this the issue where it's being done? (It's listed here under low priority backlog.)
In the field, if a scout enters data and submits them while they're offline, the form submission to supabase will fail and they're instead being shown a QR code. What happens then? Are they going to scan the QR code at the head scout's laptop or mobile device? Does this work sufficiently well?

Aiden and I briefly discussed how one could do an offline-first or offline-secondary approach. Supabase doesn't appear to be well suited for this, at least according to the author of rxdb-supabase, which provides a layer to add such offline support. rxdb-supabase has however only 177 stars and the last commit was 2 years ago, and low activity AFAIS.

Firebase is an offline-first framework but would require switching the storage backend from supabase to firebase (ask Codex to do it?)

Options I see:

• Understand and improve the original QR-code based design for offline submission
• Switch to firebase, which should allow normal use of the application
• Try to use an offline layer like rxdb-supabase
• Implement some support directly for this application, perhaps using IndexexDB

Comments?

[godmar]

I'll try the following approach.

• Instead of displaying a QR code with just JSON data, display a QR code with an encoded GET request that, when activated will upload the data to a vercel function that will then insert it into the database
• this way, if upload during the contest fails, scouts can take a screenshot of the QR code and then upload it with Google lens or a similar program later.

[aidnem]

I talked with @aidnem and @j0shuaS yesterday a bit about the scouting app.

Is improving offline support a priority and if so, is this the issue where it's being done? (It's listed here under low priority backlog.) In the field, if a scout enters data and submits them while they're offline, the form submission to supabase will fail and they're instead being shown a QR code. What happens then? Are they going to scan the QR code at the head scout's laptop or mobile device? Does this work sufficiently well?

Aiden and I briefly discussed how one could do an offline-first or offline-secondary approach. Supabase doesn't appear to be well suited for this, at least according to the author of rxdb-supabase, which provides a layer to add such offline support. rxdb-supabase has however only 177 stars and the last commit was 2 years ago, and low activity AFAIS.

Firebase is an offline-first framework but would require switching the storage backend from supabase to firebase (ask Codex to do it?)

Options I see:

* Understand and improve the original QR-code based design for offline submission

* Switch to firebase, which should allow normal use of the application

* Try to use an offline layer like rxdb-supabase

* Implement some support directly for this application, perhaps using [IndexexDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)

Comments?

@godmar Sorry I missed this comment, I'm not sure how I never saw a notification for it. Could we just use rxdb's supabase replication plugin and bypass rxdb-supabase entirely? The docs there look possible for us.

Related to your second comment: I think the QR code idea is good. As long as we can get internet access good enough to submit all of the GET requests somewhere at the competition venue I don't see why it wouldn't work.