Efficient Construction of Visualization Datums and Option Sets

[bencap]

Partially motivated by #610 and partially motivated by the prevalence of additional data fields and larger data sets on the platform, we should take time to think more clearly about how visualizer data sets are constructed so that we can reduce the amount of duplicate work we perform across the variant space of a score set.

At present, visualizer components handle their own data manipulation and prop building. Although generally fine for smaller score sets and when we had less options, this decision is starting to put some strain on site load times for larger score sets now that we have more option properties and are handling generally larger variant sets.

We should consider bumping construction of visualizer datums up a level to the score set view and passing them to the score set histogram and score set heatmap as visualizer props. This would allow us to construct such variant sets a single time, reducing duplicate work across child components when the site is initially loaded.

We should take special care to build these in such a way that is consistent with child visualizations. For instance, we would need some mechanism to efficiently switch between a protein and nucleotide heatmap when both were available to be displayed.

A possible implementation would look like:

// score set receives variant datums from the API
variants = api.get(variants)

// track visualizer options to pass to child components
vizOptions: {
    canDoThisInVisualizer: False
    cantDoThisInVisualizer: True
}

// construct variant datums one time
for variant in variants:
    const variantDatum = {
        prop1: variant.prop1,
        prop2: variant.prop2,
        ...
        propN: variant.propN,
   }

   // update visualizer options based on presence/absence of properties
   if ( ... ):
       canDoThisInVisualizer = True
   if ( ... ):
       cantDoThisInVisualizer = False

// pass visualizer datums to child components

If implemented in this way, we should consider what we might need to do to unify the datum properties between viz components. Note though a side effect benefit here would be to simplify tracking of selected datums across visualizer objects (see #598 for the current implementation).