-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tooltips remain after a filter removes the element from the track #206
Comments
@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:
|
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,
]
})
]
})) |
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
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 inthis.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 onthis.data
, but arcs are rendered based onapplyFilters
. Thus, a tooltip can be drawn for an element that isn't really there!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.The text was updated successfully, but these errors were encountered: