Refactor frontend query tool

[surchs]

Context

Vue2 is end of life since December, Nuxt2 will be this summer. So issues like neurobagel/annotation_tool#533 both become more frequent and harder to fix. Although LTS for Nuxt and Vue exists, the maintenance cost will likely become larger and migrating to a newer framework is most likely the right call and cheaper in the mid term. So we decided to move away from Nuxt2/Vue2.

The obvious choice would be to go to Nuxt3. There are a couple of reasons why we won't do that:

• The Vue2-Vue3 transition has been slow for third party library support like component libraries. This is even more so the case for Nuxt3, which is not (yet?) supported e.g. by Cypress. So the ecosystem hasn't caught up yet, and existing solutions don't have a large userbase.
• Nuxt is a SSR framework. And while we get a bunch of quality of life features (file system routing, imports, fetch...), we ultimately don't need SSR for our tools. We pay for the convenience of Nuxt3 by being an even more niche framework than Vue3 - again making third party support worse
• We mainly picked Vue because we thought that it is the more accessible framework for contributors who may not be very familiar with JS. The first part is probably true, but out actual community is mostly using React. Certainly most freelancers do.

So bottom line: Nuxt (or any SSR) is overkill for our purposes. And for maintainability, third party ecosystem, documentation, availability of contributors React is superior to Vue. So we decided to migrate from Nuxt2 to React. We will do that with the query tool first.

https://miro.com/app/board/uXjVN9R29Aw=/?share_link_id=256256517932

Why

• to update our tech stack for frontend services to a current framework
• to benefit from a wider tool and developer ecosystem
• to benefit from existing solutions for auth in the near future
• to ensure maintainability of the project frontend tools in the future

Outcomes

• A new react based query tool repo exists
• Build and dev tools are configured to current best practice and documented
• We have a tested query tool that has feature parity with the legacy Nuxt version

What

• Create query prototype query-tool#1
  • only one submit button
  • no query fields
  • tool renders the API response nicely
  • no UI sugar (toast, ellipses, blocking UI elements)
  • results cannot be selected
  • no download
  • no node selection
• Implement query fields query-tool#2
  • query fields for the variables exposed by the API are added
  • query selections are reflected in the API request being sent out
  • UI element blocking (healthy control <-> diagnosis)
  • fetch the options for variables from the API at startup
• Implement Node selection query-tool#3
  • fetch the list of nodes from the API (with error handling)
  • default selection is all
  • User can select nodes and that becomes part of the request
• Parse node selection from the URL query parameters query-tool#4
  • selected nodes are read from URL query parameters on App launch
  • user node selections are written to the URL query parameters
  • base outcome: I can copy/paste URL with node names and recreate node selection state
• Implement logic for downloading result query-tool#5
  • select cards
  • download data
  • Alerts
• UI improvements query-tool#14
  • Alerts
  • name ellipses
  • overall stats
• e2e tests query-tool#18
• component tests query-tool#20
• Add appzi query-tool#28
• Set up CIs query-tool#27
• Configure deploy on release on GH pages query-tool#41
• Rename repo to query-tool and archive legacy tool query-tool#42