Open KCMertens opened 4 months ago
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.
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.
saxon-js
can compile in the browser these days I hear) implemented as an API in the backend, though not used in the frontend yetindex.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:
form
andsubForm
properties determine what the shape of theformState
property is, leading to lots of error-prone code whenever reading values from it.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.filters
module that can handle composite filters (such as dates) that are not defined in the corpusannotations
module that does the same for things likeuiType=pos
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.