locuszoom
locuszoom copied to clipboard
Tooltips remain after a filter removes the element from the track
Filtering operations allow controlling which elements are rendered.
However, an open tooltip will remain even after its parent element has been removed by a filter + re-render operation.
Steps to reproduce
See coaccessibility demo: https://statgen.github.io/locuszoom/examples/coaccessibility.html
- Click on a loop with score = 0.5
- Using the textbox widget, apply a filter (score >= 0.9)
- See tooltip remain
Initial diagnosis
It appears that the rendering pipeline operates on this.data
(the unfiltered set)- effectively, global state. When we re-render, the preserved internal state ("a tooltip was here") sees an annotation for an element with a matching entry in this.data
, and concludes it is safe to redraw this element.
We'll need to refactor our rendering pipeline towards a more functional style so that tooltips are drawn based on the filtered set as determined by the render
function.
Links:
tooltips
are rendered based on this.data
, but arcs are rendered based on applyFilters
. Thus, a tooltip can be drawn for an element that isn't really there!
- When a datalayer is rendered, it decides whether to draw any "state" values that it remembers. This includes "show tooltip". State decisions are based on the full, unfiltered data
- When a data layer is rendered, it also decides whether to draw any arcs. This is a separate decision: the filtered dataset is known only to the
render
function. - The function that sets element status may be called more than once, before, or after, the render function.
Other notes
The internal store of tooltip state also has some bugs: it is not always clearing the has_tooltip
annotation successfully, even when a tooltip is deselected. The best fix would probably to simplify and "linearize" the existing rendering pipeline- it's super tangled, and state is passed from many different places.
@Parul-Kudtarkar , here's the debug code we wrote during the call. Essentially, any time any function in any data layer is called, this code writes a message to the console that looks like this:
Called data layer method getElementId for layer Arcs
https://github.com/abought/locuszoom/blob/demo/instrument-callers/esm/registry/data_layers.js#L12-L21
Kenneth at the Broad also reports seeing this in some match events. He may add more details to the ticket later.
When I click on a new match in one datalayer, and then I click on another in the other datalayer, the tooltip which popped up in the previous layer then pops up again.
The result is two tooltips being displayed, and the second tooltip irrelevant to the match not changing its type.
I'm using v13 beta-3. This is the config
this.plot.addPanel(LocusZoom.Layouts.get("panel", "association_catalog", {
data_layers: [
LocusZoom.Layouts.get("panel", "association_catalog").data_layers[0],
LocusZoom.Layouts.get("panel", "association_catalog").data_layers[1],
LocusZoom.Layouts.get('data_layer', 'association_pvalues_catalog', {
match: { send: 'assoc:position', receive: 'assoc:position' },
color: [
{
field: 'lz_highlight_match', // Special field name whose presence triggers custom rendering
scale_function: 'if',
parameters: {
field_value: true,
then: 'red'
}
},
...LocusZoom.Layouts.get('data_layer', 'association_pvalues_catalog', { unnamespaced: true }).color,
]
})
]
}))
this.plot.addPanel(LocusZoom.Layouts.get("panel", "annotation_catalog", {
data_layers: [
Object.assign(LocusZoom.Layouts.get("panel", "annotation_catalog").data_layers[0], {
match: { send: 'catalog:pos', receive: 'catalog:pos' },
color: [
{
field: 'lz_highlight_match', // Special field name whose presence triggers custom rendering
scale_function: 'if',
parameters: {
field_value: true,
then: 'red'
}
},
...LocusZoom.Layouts.get('panel', 'annotation_catalog').data_layers[0].color,
]
})
]
}))