Integrate new Capture interface with upstream Rails application

[jywarren]

Copying in info from publiclab/plots2#9257 !

Our newly revamped and tested library at spectral-workbench.js was designed to work both on its own (https://github.com/publiclab/spectral-workbench.js/) or as a JavaScript component in a larger system, the spectralworkbench.org Rails application. Work on the standalone library is nearly complete and this project will take on the integration of the newly revamped and re-organized code into the parent Rails application, following a pattern shown at https://github.com/publiclab/inline-markdown-editor for housing a JS project within a Rails project. Parts of this project are already included for displaying saved and graphed data at pages like https://spectralworkbench.org/spectrums/205427 (see integration at https://github.com/publiclab/spectral-workbench/blob/98dbde7a881788f7bd48db59eee616d6de70054b/app/views/spectrums/show2.html.erb#L22-L29), but the new code will replace the live capture interface at https://spectralworkbench.org/capture/, and will need to be able to access the following server-side resources and routes:

• fetching recent calibrations by the logged-in user
• prompting people to log in to save data
• detecting the need to calibrate and directing people to the appropriate page and/or docs
• fetching the most recent calibration and using it to display calibrated data

The current JavaScript code at https://spectralworkbench.org/capture performs all of this, and should be saved at https://spectralworkbench.org/capture/legacy, while the new code should be launched first at https://spectralworkbench.org/capture/new and compared for feature parity with the legacy version before any legacy systems are move or modified. The project will also require some Rails full-stack system tests to confirm functionality in the new UI.

---

And some clarifying comments here as well:

Hi @jywarren and @cesswairimu, I had a few questions regarding the spectral workbench integration project idea under GSoC. Pls have a look. Thanks :)

1. Does this require the live capture interface code to be re-written in order to integrate with ruby on rails ?

• I think /some/ of the new live capture code may need to be adapted to interface with the Rails server, for example to fetch recent calibrations. Note how https://publiclab.github.io/spectral-workbench.js/examples/new-capture/ doesn't have a selector for previous calibrations nor apparently a way to display a scale on the horizontal axis of the graph once one is applied. https://spectralworkbench.org/capture/ does have this (using a much older version of the capture interface that's messily baked into the Rails app code)

2. And if so, where do we want to integrate it to, is it supposed to be integrated at https://github.com/publiclab/spectral-workbench or some new domain altogether since the project inline-markdown editor is integrated into the plots2 project I believe…
3. But then how is the current spectral workbench working then, since there is already a RoR integration - https://github.com/publiclab/spectral-workbench .

• Here's a good example of how the .js library is integrated into the spectrum display page: https://github.com/publiclab/spectral-workbench/blob/main/app/views/spectrums/show2.html.erb#L22-L34 - however, the capture code is not yet done this way, because the old version was just kept within the Rails app project code. But it would happen in a file kind of like this: https://github.com/publiclab/spectral-workbench/blob/main/app/views/capture/index.html.erb#L135-L144. Also note that we would likely attempt this in a second "beta" file like we did with /app/views/spectrums/show2.html.erb - so for this, /app/views/capture/index2.html.erb perhaps? That way we don't risk the current working version while trying to integrate the new one.

4. And do we need a db to store the values for the login users assuming option 1 is correct ?

The Rails app should manage all user data! We should be able to "build in" the JS functionality for the capture interface similarly for how we did for the spectrum display interface, with the Rails app managing all the stateful back-end and database and even data management, and a pretty minimal "handoff" of new data from the capture interface to the "host" Rails app. See how the original JS code from long ago managed both saving new spectra (using an HTML form on the page to submit) and fetching calibration data: https://github.com/publiclab/spectral-workbench/blob/main/app/assets/javascripts/capture.js#L356-L385 You can see where the server responds to these requests on the server side in this controller: https://github.com/publiclab/spectral-workbench/blob/main/app/controllers/capture_controller.rb

5. Are there any enhancements that can be considered if option 1 is correct and the code is to be rewritten altogether ?

Much of the new capture interface at https://publiclab.github.io/spectral-workbench.js/examples/new-capture/ is already written, but there may need to be some new code adapted from the previous version for:

1. fetching recent calibrations
2. displaying them in a list to choose from
3. using a chosen calibration to display a scaled x-axis on the new capture interface's live graph
4. saving data to the host Rails app as was done in previous versions of the capture code
5. submitting the chosen calibration reference to the Rails app along with the newly captured data

This is still a pretty substantial project but it's nowhere near a rewrite of the capture interface itself! I hope this is helpful!

---

This is quite a large project and would have to be broken up into smaller parts. It would also involve coding in both this repository as well as https://github.com/publiclab/spectral-workbench/

Thank you!!!

[waridrox]

Hi @jywarren, I wanted to know your thoughts on using rear camera for live capture feed instead of the front camera on mobile devices.
Since, I think with rear camera it is easier for the users to align the spectral data while seeing the full un-obstructed preview on their screens. Or better if we give users the option to switch between front and rear camera perspectives. 🤔

[jywarren]

It's very true - camera direction selection is critical! I believe this can be achieved with the new capture code and I've made a brief note of it here: #190

There are links to camera configuration settings there; my understanding is that if we configure it correctly we'll get rear camera as default. I think the ability to 'switch' cameras might possibly be a distinct issue. Feel free to create and/or expand issues on these! Thanks a lot!

[jywarren]

This is essentially complete, due to great work by @waridrox!!!

There are some follow-ups. Let's move to publiclab/spectral-workbench#645 for them.