Preparations for Vue 3

[KCMertens]

Upgrading to vue 3 is not currently ongoing!
This is simply an issue to track progress on several underlying problems that need to be solved for a smooth migration.

Moving to a single page application

This will be the biggest hurdle probably.

• How do we handle changing from one corpus to another?
  An easy stop-gap solution is to detect this (in vue router?) and just hard-reload the page. Then we don't have to deal with cleanup.
  If we want to do it property:
  • The store will need to clear itself, and load the new corpus info
  • Old customJs and customCss will need to be unloaded
    This will require a more formal customJs api so you're forced to deal with it while writing it.
  • We'll need to create a bit of API that allows getting the new corpus's configuration, such as the navbar items, favicon, tracking code, etc. Code for this largely exists in the api requesthandler
  • We'll need to create a bit of API that returns document contents/metadata (or move xslt to the browser entirely, saxon-js can compile in the browser these days I hear) implemented as an API in the backend, though not used in the frontend yet
  • The servlet will always have to return the normal index.html (or whatever we use) **Is a relatively easy fix. Removing the default errorpage response and replacing it with one that returns index.html instead. **

The vuex store

The store will need probably a complete redo, as we'll need to rewrite it in vue 3 anyway.
The store currently uses vuex-typex which is not supported in vue 3, (vuex is no more) to get type safety and remove some boilerplate we'd otherwise need. But we can't take this with us.

Particular warts I'd like to get rid of:

• async initialization of the corpus module. Right now this is required because when the page loads we don't know for sure whether the current user is allowed to see the corpus. Impossible, we can't have an SPA without having to reload the corpus (i.e. async behavior) on the fly
• the other modules having to wait for the corpus module to finish initializing Impossible. See above.
• The query and history module having a horrendous type, where the form and subForm properties determine what the shape of the formState property is, leading to lots of error-prone code whenever reading values from it.
• The views module being some weird factory that can in theory add extra views (besides docs and hits)
  I'd much rather just have some duplicate code in the state shape/getters/setters than all the magic to dynamically instance store modules
  Perhaps we can do something with composition. I.e. getting the query (with some parameters, pagination yes/no, grouping yes/no, sorting yes/no, only docs, only hits.), getting the results, some transformation functions for the results.
• The filters module that can handle composite filters (such as dates) that are not defined in the corpus
• The annotations module that does the same for things like uiType=pos
• i18n on filters and annotations. These are usually gotten directly from the store, but because translation happens in the component, this means that every time we want to render these objects we need to remember to translate the display names and values. This happens repeatedly in multiple places in the application and is easy to forget. It would maybe be better to not have the components do this at render time, but translate the values directly in the input objects. This would mean that the vuex store that currently provides the MetadataFields, FilterDefinition, and Annotation objects would need to be aware of the translation process though. Maybe we can come up with a better solution than either of these options.
  It would be good to look at this when/if we overhaul the store for the vue 3 migration.

Lower prio work:

RXJS

Organize the streams files, see if we can remove some streams, notably rewrite url and history generation. A regular listener on the store should suffice and be simpler.

[jan-niestadt]

The store will need to clear itself, and load the new corpus info

Maybe we could store corpus information by corpus name? That way, you don't have a single instance of corpus info that you have to (properly) clear and reload (with a lot of potential bugs that put it in a broken state), but can just create a new corpus config object under that corpus' name. Maybe you could have a computed property that always points to the current corpus (if any).

Of course, you don't have to keep corpus info for all corpora in memory; you can just drop everything except the current corpus' info.

I don't know if this is a good idea or not; depends on what's more complex to implement/maintain of course.

async initialization of the corpus module. Right now this is required because when the page loads we don't know for sure whether the current user is allowed to see the corpus.

I'm not sure what you mean by the async loading of corpus info and user permissions. If a user isn't allowed to see a corpus, it's probably alright if they can see the size and fields in the corpus, right? It's the content that's restricted, not the metadata.