Customizing default view: defaultSession or embedded js code?

[abretaud]

Hi!
I'm getting back to work on the galaxy tool to generate jbrowse2, trying to finally finish it.
Thinking about it, I'm not sure I'm doing things the Right Way©. Basically I'd like to generate jbrowse2 "datasets" (dir with ready to use jbrowse static files), with for example a genome and a few tracks.

Specifically I'd like to preconfigure what is displayed when the user opens this kind of dataset, like:

• open by default a LinearGenomeView for assembly X
• zoom to a specific initial position on the assembly
• display some of the tracks by default
• change some track options (show label or not, etc)

For now I've tried to do all this with a defaultSession in config.json, but I realize that maybe I'd better embed my jbrowse in a custom html page where I can add JS code to do this "preconfiguration" (like https://jbrowse.org/jb2/docs/tutorials/embed_linear_genome_view/07_default_session/ ?).

I feel like I can't do everything I want using a defaultSession in config.json. Maybe I'm wrong though 🤔 .

What do you think about that?

(kind of related to the questions I asked in #2708 last year)

[cmdcolin]

There are a couple different aspects to your question

Deciding which 'product' you want

You can decide if you want

a) the full "JBrowse Web" application (which has multiple view types, circular, dotplot, linear, synteny, and uses a config.json, url parameters)
b) the embedded linear genome view (which is just a single linear genome view, and you control the code that sets it up)

Your choice may vary depending on your needs

Choosing the "JBrowse Web" application

For the full jbrowse web application, setting up the config.json will get you most of the way there, and I recommend actually using the URL parameter API to do some of the tasks you want. Hand coding the defaultSession is difficult because it is an internal representation of the app state that is, unfortunately, not easy to programmatically generate or hand edit (offsetPx/bpPerPx for example are do not easily map to a specific locstring, and we don't have a way to easily use locstring in the session)

The URL query parameter API makes it easy to do 90% of what you might want, e.g. like this

http://host/jbrowse2/?config=test_data/config.json&loc=chr1:6000-7000&assembly=hg19&tracks=gene_track,vcf_track

You can have the query params set up in an iframe or a stand alone page. This satisfies your first three questions, and your fourth (show track label or not) might have some other solution. The show track labels is currently part of the app state, but could be added to the config or a URL parameter.

Choosing the embedded LGV

The embedded use case of the app is an alternative approach, and there are some interesting considerations for it. The embedded use case is more minimal, it let's you control a single instance of a linear genome view, and it has no connection to a config.json or url parameters. We expect that a developer using the embedded view can fetch from a JSON file manually to pass to the createViewState constructor for example if they wanted to use an actual config.json type file, and similarly, for fetching URL params.

This means that it requires more developer effort in some cases, but you may also have more control. You can also explicitly call functions like "navToLocString" and "showTrack". Click "Show code" here to see how showTrack is called https://jbrowse.org/storybook/lgv/main/?path=/docs/getting-started--docs#opening-up-tracks-by-default (to show tracks by default in the embedded lgv, you can imperatively call showTrack one or more times for each track you want to show).

Note that there can be some drawbacks to the embedded LGV also. It is not configured by default to use web workers, which can make some operations like alignments tracks slower. Developers can add web workers to the embedded LGV, but it takes a little effort, and it is only documented when using create-react-app at the moment. See https://jbrowse.org/storybook/lgv/main/?path=/story/linear-view--with-web-worker and https://jbrowse.org/jb2/docs/embedded_components/

Another future option

If you are strongly interested in the embedded option, but also like the full "JBrowse Web" app, we have considered adding a packaging of the "JBrowse Web" app that can be used programmatically, see #3531

If there is interest in this, let us know

[cmdcolin]

See https://jbrowse.org/jb2/docs/urlparams/ for more info on the URL query parameter API

[abretaud]

Thanks for the detailed answer 👍 !

Choosing the "JBrowse Web" application

Hand coding the defaultSession is difficult

Yes, that's what I felt while trying to do it 😄

I was not considering using URL params until now, because from galaxy I can't pass them directly, I just get links like https://galaxy.example.org/datasets/<random_id>/display/?preview=True in the history, which I can't really customize. But if I can hide it in the index.html code somehow, why not. It would be a simple solution for locstrings and default assembly/track selection. Not very fond of iframes though, but maybe there's a modern alternative now!?

The show track labels is currently part of the app state, but could be added to the config or a URL parameter.

Yes, I remember I made some attempts at customising that, but I found it tricky/impossible indeed. Here I spoke about "show track labels", but I planned to do this for several most common track options, of different track types. I wonder if there could be a generic way to make these options configurable by config/url? I mean it would be painful if we need to change some jbrowse code to expose an option everytime I want to make it customizable from the galaxy side

Choosing the embedded LGV / Another future option

I've just realised that in the current embedded mode, it was just the linear viewer (or circular, whatever) and the rest of the jbrowse app was not (yet) accessible. So the "future option" fits probably better with what we try to do.

In fact our use case looks like that:

• from galaxy, user A generates a jbrowse2 dataset, with some "good" default settings for location/tracks/track options
• user A shares its dataset to user B and C
• user B has basic usage: he just looks at the default view, with very limited changes to options.
• user C is a power user: she just looks at the default view, but can decide to do whatever she likes, add new tracks, change from linear to circular etc

Maybe you have some thoughts on this too @hexylena?

[hexylena]

I was not considering using URL params until now, because from galaxy I can't pass them directly, I just get links like https://galaxy.example.org/datasets/<random_id>/display/?preview=True in the history, which I can't really customize. But if I can hide it in the index.html code somehow, why not.

I think the iframe works well enough. We can't change the parent galaxy URL, but we can absolutely write out our own index.html that wraps jbrowse

It would be a simple solution for locstrings and default assembly/track selection. Not very fond of iframes though, but maybe there's a modern alternative now!?

would be cool!

So the "future option" fits probably better with what we try to do.

I think we can probably achieve this now just with the url params, and the full jb2 rather than just LGV, but I trust your experience there @abretaud I haven't worked with it enough :/

I think there's an argument for our tool to have a selector of:

• full jb (default)
• LGV
• circular
• etc

and then when the user builds the JBrowse instance, they select that and it's "fixed" to that view.

[abretaud]

Hi!
Resurrecting this discussion, as we're making progresses on our jb2-in-galaxy project.
I've switched to using an iframe + url params, and it looks great for my first 3 points:

• open by default a LinearGenomeView for assembly X ✔️
• zoom to a specific initial position on the assembly ✔️
• display some of the tracks by default ✔️

For my last wish, "change some track options (show label or not, etc)" I wonder if now there's a way to do it using urlparams? Something generic to access each track display type options would be awesome