API to support utility visualizations in Gosling

[sehilyi]

Utility visualizations (or metadata visualizations) include tables, trees, and other summary visualizations that are often visualized together with genome-mapped data visualizations (often with coordinated interactions). We want to determine the best way to support this.

Option 1 - Extending Gosling Grammar

The user only has to write a single spec, so good for reusability. Nesting utility views and genomic views can be made possible. The challenges are to unify the grammar.

{ 
   type: 'genomics', tracks: [...]
},
{
   type: 'vega-lite', ...
},
{
   type: 'table', ...
}

Option 2 - Optional Spec for Utility Visualization in Gosling Component

This is similar to how we support Gosling theme specs in Gosling Component:

<GoslingComponent spec={...} utility={...}/>

The user does not have to switch to another component. We can have an entry for adding/editing a spec for utility visualization on the editor.

Option 3 - Create React Component around Gosling for Utility Visualization

<GoslingUtilityComponent spec={...} utility={...}/>

I initially was leaning towards the third option (before thinking about Option 2), but I like the second option more, given that it supports rendering utility visualization using the same component. I am also open to Option 1 or other alternatives.

cc @ThHarbig (feel free to edit/add this directly!)

[manzt]

I think I understand the motivation, but I'm weary of options except Option 3. The proposed solutions tightly couple Gosling with other libraries, implicitly making vega-lite and others dependencies of Gosling. This feels eerily similar to the issues that we have with HiGlass right now, so I'd be very careful of the approach we decide on.

To illustrate, we want to use HiGlass without React (and many other dependencies) now, but can't do so flexibly. This is causing real issues for developers and users of HiGlass because HiGlassComponent is an "app", not a library. We don't want or need React things at all from HiGlass in Gosling, and we are still trying to think of ways to reverse this design. For developers, it means it's increasingly difficult to manage dependencies, and for users it means more bloated tools which could have downstream performance challenges (slower loading, etc). HiGlass optimized its design for the "app" use case, but now we want to use it as a library and that has many challenges. It's my understand that we want to do the same with Gosling.

As a general purpose grammar of graphics for genomics, we should think about how to "connect" our domain specific tool with existing tools (composition), rather than depend these tools internally. This approach forces us to think of what interfaces we need to expose from Gosling to connect with existing tools/frameworks.

Some points for discussion (I know I missed the meeting today, so forgive me if I'm repeating things):

• What are the current challenges with connecting Vega-Lite or a Table component with Gosling?
• What does the end product of this toolkit for metadata visualizations look like for Gosling?
• Are we reinventing the wheel (e.g., Vitessce connects many different visualizations)?

In summary, Gosling is already a very large toolkit that sits on top of another very large toolkit (HiGlass). We are actively trying to work backwards from this type of design at the moment. Bundling features/tools together is often done out of convenience because the current project doesn't lend itself to extensions easily. What can we do to improve that situation?

[ThHarbig]

Thanks for opening this issue! I am open to all three options in principle. My initial idea was to extend gosling as an "app", which would mean being able to incorporate utility visualizations into gosling directly in the editor, but I am fine with simplifying the ways to connect gosling with other tools externally as well!

Apart from some API fine-tuning tables/other components can already be connected with gosling (e.g. #894). But there are some scenarios that might be a bit harder to do, for example when we have a nesting of metadata views and genomic views (I am still exploring this at the moment).

We agreed that we have to at some point "draw a line" because we do not want to open up gosling to the whole world of visualizations, but I think there might be some value in having an easy solution that does not require setting up a whole project for some of them, such as a simple metadata table or an attached phylogenetic tree.

[sehilyi]

Revisiting this, I wonder if making gosling-lang/gosling.js a monorepo can address the dependency issues. Ideally, it would be best if users could use the same component (i.e., <GoslingComponent/>) regardless of using utility visualizations. If they wish to use utility visualization, they will need to additionally install a required subpackage (e.g., @gosling-lang/utility-visualizations or more scoped ones like @gosling-lang/tree) and provide additional specs to the component, like the Option 2. Unsure exactly how we can technically achieve this, but we can probably get ideas from Vitessce since AFAIK it loads HiGlass (or Vega) only when needed, but users only need to use a single component, Vitessce.

[manzt]

can probably get ideas from Vitessce since AFAIK it loads HiGlass (or Vega) only when needed, but users only need to use a single component, Vitessce.

The top level Vitessce is a "batteries-included" configuration of vit-s. This means the VittessceComponent functions much more like an app, but developers can create a similar configuration with just the features they need from the other subpackages.