Use Results class for visualisations

[lukavdplas]

Results is an abstract class in the frontend that is designed to handle various types of results based on a query. A child class will have some parameters of its own (or none), and fetch results when the query or the parameters change.

This class is currently used to fetch the (paged) document results for a query, but it was written so that it could also be the basis for visualisations. The advantage of this is that Results includes some logic that won't need to be repeated for every visualisation. It also results in a more consistent flow in the application.

However, visualisations are complex modules that tend to include some complex logic of their own, so this refactor isn't trivial

To fully use the Results class, I would propose (in this order):

• a FrequentWordsResults class that generates results for the wordcloud.
• an NgramResults class that generates results for the ngram visualisation.
• a DocumentFreqResult class that generates a histogram of document frequency in relation to a keyword or date field. Create subclasses for those two scenarios. Used for the document frequency graph.
• a TermFreqResult class that generates the frequency of the search term in relation to a keyword or date field. Used for the term frequency graph.

Some considerations:

• The wordcloud is the easiest case, because it doesn't feature any additional parameters or extra logic.
• The ngram visualisation has a lot of parameters, but that should map well to how Result already works.
  • An additional complexity is the use of caching, but I don't think that should raise any particular difficulty. Write NgramResult.fetch() so it uses the cached data in the same way that NGramComponent.loadGraph() currently does.
  • Another issue is that you need to request that the visualisation task is cancelled when the model stops observing it - usually because the parameters change.
• The document frequency graphs have a straightforward fetching function, but for date histograms, they have the complexity that we need to fetch higher-resolution data when zooming in (e.g. per month rather than per year), and project the data for the zoom window onto the current data in the graph. Not sure how to go about this. Create an additional DocumentFreqResult for the smaller interval?
• At this point, writing the TermFreqResult should be relatively straightforward. However, the barchart module is a beast - refactoring it to use the DocumentFreqResult or TremFreqResult is welcome but not trivial.

Bonus points:

• a AggregationResult class that fetches the document counts displayed in the multiple choice filter. Could also be based on DocumentFreqResult.
• a CountResult class that just fetches the total number of documents, that can be used in the download component (used to determine the download type).