statgen / locuszoom

A Javascript/d3 embeddable plugin for interactively visualizing statistical genetic data from customizable sources.
https://statgen.github.io/locuszoom/
MIT License
156 stars 29 forks source link

Is it possible to reference custom data fields in the LocusZoom tooltip? #267

Closed vb-tony closed 2 years ago

vb-tony commented 2 years ago

Hello!

I have a quick question about whether something is possible within the existing LocusZoom libraries.

When creating an association panel for a plot, we use a custom association adapter for our data source so that we can leverage our own APIs to return the required data (such as chromosome, ref allele, alt allele, pvalue, etc...) needed by LocusZoom to generate the panel.

If we were to return additional data in the APIs (i.e.: data fields that are irrelevant to creating the panel), would it still be possible leverage this data elsewhere like in a tooltip? If so, how can that be done?

Example: If our API returned a data field called 'RSID', could we reference 'RSID' in a tooltip?

I saw in the documentation that you can reference fields using {{<assoc_name>:fieldname}} but I've only been able to get that to work for the fields that LocusZoom knows about.

Thanks so much! Anthony

P.S.: LocusZoom has been a great tool for us. Thanks so much for continuing to support the project!

abought commented 2 years ago

Thanks for the question!

In the past, adapters had a (frankly annoying) limitation where they only gave you back the API fields listed in the data_layer.fields = [...] section of the configuration; other fields got silently dropped. Back in those old days, if you wanted to see all the fields from your custom adapter, you could write something like this.

This was legacy syntax and drove me nuts, because who really remembers to change two separate sections of a giant config object? As of v14 (released a few weeks ago) that quirk is gone; custom tooltip templates can easily reference any field the API returns, no extractFields required. If your assoc api returned rsID, your template would still use the {{assoc:rsID}} syntax, as you note.

So the answer depends on exactly which version you're using; customizing your adapter will probably be the fastest solution on an old release. (the upgrade process is possible, but not effortless)

If you're already using LZ v0.14, then something surprising is happening and I'd be curious to delve further.

EDIT: If you are comfortable using your browser dev tools, and can tell the console to show DEBUG level error messages, LZ 14 will now print a console message warning you if your template asks for a field that is not present in any API response. This can help to identify small typos that aren't obvious.

vb-tony commented 2 years ago

Thanks, Andy!

We are currently using v0.13.4. I'll upgrade to the latest LocusZoom version and give it a shot.

Appreciate the quick response!

abought commented 2 years ago

If it helps, the release notes describe what changed: https://github.com/statgen/locuszoom/releases/tag/v0.14.0

I do apologize for the novel-length descriptions! In the earliest days, the team tried to handle "every possible type of data from anywhere", which resulted in a system with a lot of abstraction. The goal of these changes was to reduce... some... of the magic (and move to stricter rules about what fields are present, like log_pvalue).

Unfortunately, this meant introducing some visible breaking changes after many years of increasingly gnarly compatibility code. Hopefully, giving you answers for the old and new versions will give you options for your situation. :)

vb-tony commented 2 years ago

Updating to v0.14.0 worked like a charm!

I also like the updates to the code and the improved debug logs. They were super useful. No worries about the release notes. I've certainly seen much longer ones but it's always nice to know all that changed as that helps with the migration process to the new version. And when dealing with such a large code base, at some point you'll have to do breaking changes, since continuing to build on the old is no longer feasible. I completely understand! 😄

Given that my question is resolved, I'll close this thread. Appreciate the help, Andy!